Closed Bug 688719 Opened 14 years ago Closed 13 years ago

Automate setting minversion/maxversion for release builds

Categories

(Calendar :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Fallen, Assigned: ssitter)

References

Details

Attachments

(2 files, 2 obsolete files)

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.
Blocks: 673089
No longer blocks: 685133
Attached patch Possible fix (obsolete) β€” β€” Splinter Review
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.*
Attached patch fix for all branches β€” β€” Splinter Review
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.*
Assignee: nobody → ssitter
Attachment #588371 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #627556 - Flags: review?(philipp)
Attachment #627556 - Flags: feedback?(mbanner)
Comment on attachment 627556 [details] [diff] [review] fix for all branches Not tried it, but looks good.
Attachment #627556 - Flags: feedback?(mbanner) → feedback+
OS: Mac OS X → All
Hardware: x86 → All
Attached patch Fix - v2 (obsolete) β€” β€” Splinter Review
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.
Attachment #629881 - Flags: review?(ssitter)
Attachment #629881 - Flags: feedback?(mbanner)
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.
Attachment #627556 - Flags: review?(philipp)
Attachment #627556 - Flags: review+
Attachment #627556 - Flags: approval-calendar-beta+
Attachment #627556 - Flags: approval-calendar-aurora+
Attachment #629881 - Attachment is obsolete: true
Attachment #629881 - Flags: review?(ssitter)
Attachment #629881 - Flags: feedback?(mbanner)
Ok, I'll wait with check-in until macosx and win32 builders are back online to ensure it's working correctly.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.8
Target Milestone: 1.8 → 1.7
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.
Attachment #644614 - Flags: review?(ssitter)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Attachment #644614 - Flags: review?(ssitter)
Attachment #644614 - Flags: review+
Attachment #644614 - Flags: approval-calendar-beta+
Attachment #644614 - Flags: approval-calendar-aurora+
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: 1.7 → 1.9
Target Milestone: 1.9 → 1.8
Target Milestone: 1.8 → 1.7
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: