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

RESOLVED FIXED in 1.0b2

Status

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

Trunk
1.0b2

Details

Attachments

(1 attachment, 1 obsolete attachment)

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.
It this still the case? It was supposed to be fixed with Bug 568000.
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.
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.
Created attachment 449599 [details] [diff] [review]
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).
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #449599 - Flags: review?(philipp)
Created attachment 449600 [details] [diff] [review]
The fix v2

Better patch produced against the 1.9.2 branch, not trunk ;-)
Attachment #449599 - Attachment is obsolete: true
Attachment #449600 - Flags: review?(philipp)
Attachment #449599 - Flags: review?(philipp)
Attachment #449600 - Flags: review?(philipp) → review+
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?
(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.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
You need to log in before you can comment on or make changes to this bug.