+++ This bug was initially created as a clone of Bug #1520365 +++

I built TB 68.1.1 here:
https://treeherder.mozilla.org/#/jobs?repo=comm-esr68&revision=bfd115c413ffa678e313c3ce33c44bbc7f28c7b3

Looks like all Calendar related MozMill tests failed. So I downloaded the binary and installed it onto a new profile.

In the add-ons manager I was told:
Lightning is incompatible with Thunderbird 68.1.1

However, Lightning is at version 68.1.1. So something as gone wrong.

I could get it installed by changing the version and strict_min_version to 68.1.0.

Wrong gecko version? From to application.ini:

Version=68.1.1
...
[Gecko]
MinVersion=68.1.0
MaxVersion=68.1.0

From manifest.json:

"strict_min_version": "68.1.1"

Wow, and why is application.ini wrong? So this becomes a build issue, right?

I was planning to do this anyway, and it will certainly help here.

There's a bunch of packaging related bugs that went into Daily over the last couple of weeks that I suggest uplifting so there's one way of calculating versions and generating those files.

bug 1569539, bug 1507754, bug 1561782, bug 1578806, bug 1578920.

Well, application.ini is still at 68.1.0 since it comes from M-C/M-ESR68. That makes it impossible to spin a x.y.Z release when they are at x.y.0 :-(

Does Thunderbird has similar restrictions regarding "strict_min_version" in manifest file as Firefox? In that case it should be "68.0" and not "68.1.0" or "68.1.1". https://addons.mozilla.org/en-US/firefox/pages/appversions/

I downloaded the binary and installed it onto a new profile. In the add-ons manager I was told: Lightning is incompatible with Thunderbird 68.1.1. However, Lightning is at version 68.1.1. So something as gone wrong.

So this is not something wrong in 68.1.0, that we need to address BEFORE users update to 68.1.1, correct?

What I am concerned about is users updating to 68.1.1 and then they (and we) face a compatibility issue that is difficult or impossible to resolve.

Actually since this build usses Firefox 68.1.0, application.ini is technically correct. This seems to be what the addons code is looking at to decide on compatibility.

I was able to get calendar to work in the above build by unpacking the XPI file that gets installed, and changing manifest.json's "strict_minimum_version" to "68.1" rather than "68.1.1".

application.ini is generated and build time then turned into application_ini.h. application.ini is ignored at runtime unless you start with some magical semi-undocumented parameter to the executable.

I think for 68.1.1, we can modify whatever created manifest.json to drop the 3rd level of the strict_minimum_version requirement. I doubt other addons will have such an issue since most seem to generate version requirements another way (eg not tied to the source like this).

Forget my earlier comments. Those uplifts won't help here unless the way manifest.json is built has changed.

Hmm ... so if my changing that strict_minimum_version to "68.1" fixes this, then that means toolkit looks at the Gecko version, not the Thunderbird version.
And here it gets ugly again, because the reason for strict_minimum_version being this way is for security releases. But if there's no Gecko update to address a security issue, like in this case Gecko stays at 68.1.0 and Thunderbird bumps to 68.1.1 there's a problem.

So yes my "fix" will deal with 68.1.1 but IMHO addon version checking needs to be modified to look at Thunderbird version, not Gecko version.

The strict_minimum_version entry in manifest.json explicitly refers to Gecko and not to Firefox or Thunderbird:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings
And at least Firefox requires that it is set to "68.0" and not "68.1" for its extensions, see comment #6.

(In reply to Wayne Mery (:wsmwk) from comment #7)

So this is not something wrong in 68.1.0, that we need to address BEFORE users update to 68.1.1, correct?

TB 68.1.0 is fine. We can currently not build 68.1.1 with a working calendar. So if we can't build it, no one will be upgraded.

(In reply to Rob Lemley [:rjl] from comment #9)

Hmm ... so if my changing that strict_minimum_version to "68.1" fixes this, then that means toolkit looks at the Gecko version, not the Thunderbird version.
And here it gets ugly again, because the reason for strict_minimum_version being this way is for security releases. But if there's no Gecko update to address a security issue, like in this case Gecko stays at 68.1.0 and Thunderbird bumps to 68.1.1 there's a problem.

Surely there's only a problem if for some reason the .1 Lightning doesn't play nicely with the .0 Thunderbird? That could happen, but seems pretty unlikely IMO.

So yes my "fix" will deal with 68.1.1 but IMHO addon version checking needs to be modified to look at Thunderbird version, not Gecko version.

I doubt the toolkit team will agree to that.

Let's just trim the strict_min_version number back to 68.1 and be done with it.

Gonna get a review?

TB 68.1.1:
https://hg.mozilla.org/releases/comm-esr68/rev/137d88da79e9161d292b32bccf0f5615a3d3b562