568772 - Stabilise the maximum version for Thunderbird in Lightning's install.rdf on the 1.9.2 branch

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Mark Banner (:standard8)]

I've just done this for Thunderbird's locale xpis (bug 567132), and I think we should do the same for Lightning and its add-ons.

The fix is:
- Change the maximum version in install.rdf from @THUNDERBIRD_VERSION@ to 3.1.*

The reasoning:
- We know that as the current versions of Lightning nightly builds are compatible with Thunderbird 3.1, there will be no further compatibility breakages on the 3.1 branch.
- Users who have/are picking up nightly builds (before Lightning 1.0b2 is released) will get confused if they upgrade to 3.1.1 and Lightning is disabled.
-- We saw this sort of effect when we released 3.0.1, and I think we had similar complaints with 3.0.3. 

This probably doesn't necessarily encourage users to upgrade nightly builds or switch to the AMO version, but I think it could reduce the amount of complaints about Lightning stopping working on Thunderbird *minor* upgrade.

Thoughts? I'd like to get this done in the next day or two if we're all in agreement.

Comment 1

[Stefan Sitter [:ssitter]]

It this still the case? It was supposed to be fixed with Bug 568000.

Comment 2

[Mark Banner (:standard8)]

It appears http://hg.mozilla.org/releases/comm-1.9.2/rev/80b719ebe194 did not do it :-(

Comment 3

[Stefan Sitter [:ssitter]]

You are right, looks like Philipp missed this important part. I second the request for the Thunderbird version and think it must be fixed for both comm-1.9.2 and the release branch.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Since the automated builds were so much trouble, I extracted the rc1 xpi's directly from the builders. I did those changes there manually. The changes I did before creating lightning(-all).xpi:

- fix version-192.txt
- change minVersion to 3.1
- change maxversion to 3.1.*
( - on mac I also needed a fix to "install" lighting into sunbird )

I guess we should add this as a changeset for the release branch and retag though.

You can find my extracted builds at http://mozilla.kewis.ch/1.0b2/ I will have them uploaded to stage soon.

Comment 5

[Mark Banner (:standard8)]

Attachment: The fix

This should do it - to land on the 1.9.2 relbranch and the 1.9.2 default.

I've also dropped SeaMonkey support in a couple of places - as SM doesn't build 1.9.2, I don't think its necessary on the default (and if you leave it in on "default" then you'd want to remember to remove it for any other release you do from the 1.9.2 branch).

Comment 6

[Mark Banner (:standard8)]

Attachment: The fix v2

Better patch produced against the 1.9.2 branch, not trunk ;-)

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 449600 [details] [diff] [review]
The fix v2

r=philipp

I'd appreciate if you could change the gdata version to 0.7 at least on the relbranch, and while you're at it change sunbird/config/version-192.txt to 1.0b2.

Does this require any retagging?

Comment 8

[Mark Banner (:standard8)]

(In reply to comment #7)
> I'd appreciate if you could change the gdata version to 0.7 at least on the
> relbranch, and while you're at it change sunbird/config/version-192.txt to
> 1.0b2.

Checked into relbranch with the sunbird & gdata versions updated:

http://hg.mozilla.org/releases/comm-1.9.2/rev/33e34acf697f

Checked into default without changing the sunbird & gdata versions:

http://hg.mozilla.org/releases/comm-1.9.2/rev/2c2d61d84d69

> Does this require any retagging?

Yes, you'll need to retag the sources.