3.48 KB, patch
|Details | Diff | Splinter Review|
1.01 KB, patch
|Details | Diff | Splinter Review|
Currently, a maxversion of i.e "7" is set during release automation. It would be nice if we could automate it to be set to "7.*" in the future.
Created attachment 588371 [details] [diff] [review] Possible fix This was an idea I had a while back for this bug. I've got no idea if it'll work or not.
Why not just change install.rdf from <em:maxVersion>@THUNDERBIRD_VERSION@</em:maxVersion> to <em:maxVersion>@THUNDERBIRD_VERSION@.*</em:maxVersion> ?
(In reply to Stefan Sitter from comment #2) > Why not just change install.rdf from > <em:maxVersion>@THUNDERBIRD_VERSION@</em:maxVersion> > to > <em:maxVersion>@THUNDERBIRD_VERSION@.*</em:maxVersion> > ? This would make the maxversion 9.0.*, which should work out fine unless Thunderbird decides to release a 9.1. Also, it would set the maxversion to 12.0a1* for nightly builds, which seems a bit strange. Personally I'd suggest to use a python script that also works for the seamonkey version, i.e will translate: ([0-9]+)\.0 --> \1.* ([0-9]+\.[1-9]+) --> \1.* and otherwise return the version as passed in. In spirit of ssitter's comment, maybe we could also translate: ([0-9]+\.0[ab])([0-9]+) --> \1.*
Created attachment 627556 [details] [diff] [review] fix for all branches This patch uses a solution similar to the one in Bug 723138. For XYa1 or XYa2 version the maxVersion is the same, otherwise it will be XY.*
Comment on attachment 627556 [details] [diff] [review] fix for all branches Not tried it, but looks good.
Created attachment 629881 [details] [diff] [review] Fix - v2 Hmm would anything speak against fully automating the Lightning version number, say like this? If so, then r=philipp on the previous patch. If not, please review.
Mhh, not sure. Currently Lightning is coupled to Thunderbird release cycle. But maybe this changes once libical is replaced? Or does this work for e.g. ESR releases labeled x.y.*?
I think if we change the versioning scheme we can still change the script. I also think that even if we have libical replaced, we should just stick to the version numbers and if we skip a release also skip a version number.
Oh as long we don't land this on comm-esr, it will also work for ESR releases.
Maybe your patch should be separated from the problem we tried to fix here. I don't think it will work for comm-beta now unless you want to change the version schema. And as far as I know the mozilla17 branch will be the next ESR branch, i.e. you would have to backout the patch than.
Comment on attachment 627556 [details] [diff] [review] fix for all branches Sounds good, lets do that. I'd suggest to push this on comm-central first, give it a test run and if that works out then push this down to beta.
Ok, I'll wait with check-in until macosx and win32 builders are back online to ensure it's working correctly.
Created attachment 644614 [details] [diff] [review] Fix Thunderbird maxversion for releases The first build with this patch just went through and produced a maxversion for Thunderbird of 15.0.*. What we need though is 15.*. This patch fixes.
I don't think so. We only want to support security updates automatically. 15.0.* is the expected outcome and matches what is done for other automatically build extensions.
Unfortunately 15.0.* is not a supported maxversion on AMO though. I didn't actually check if this is an oversight or if it has always been this way. I know we've been using 14.*, 13.* in the past though.
I believe fixing Bug 516026 - Ship SeaMonkey with integrated Lightning on as default would eliminate the need for this bug.
(In reply to Worcester12345 from comment #18) > I believe fixing Bug 516026 - Ship SeaMonkey with integrated Lightning on as > default would eliminate the need for this bug. I understand you would really like to see Lighting integrated with Thunderbird/Seamonkey, but please refrain from commenting about this any more bugs. We know your opinion by now, and although I see some value to shipping Lightning integrated I don't see this happening in the near future. I believe the reasons have been mentioned often enough, but the main reasons are that Lightning's performance is just not good enough for integration and also we don't have enough regular contributors to support the codebase inside Thunderbird. Even if we shipped Lightning with TB/SM, it would remain an extension so its easier to separate the code and allow users that don't need calendaring to easily disable the features. Therefore this bug would be very much relevant then too.
Comment on attachment 644614 [details] [diff] [review] Fix Thunderbird maxversion for releases Using this would really make the release process easier for me. I think we should file a new bug (in Thunderbird/AMO land) if the supported versions should be changed.
Pushed to comm-central changeset 9c51b6b891ca
Backported to releases/comm-aurora changeset 5bfe2d757514
Backported to releases/comm-beta changeset eab42b091d5d