Closed
Bug 688719
Opened 14 years ago
Closed 13 years ago
Automate setting minversion/maxversion for release builds
Categories
(Calendar :: Build Config, defect)
Calendar
Build Config
Tracking
(Not tracked)
RESOLVED
FIXED
1.7
People
(Reporter: Fallen, Assigned: ssitter)
References
Details
Attachments
(2 files, 2 obsolete files)
3.48 KB,
patch
|
Fallen
:
review+
standard8
:
feedback+
Fallen
:
approval-calendar-aurora+
Fallen
:
approval-calendar-beta+
|
Details | Diff | Splinter Review |
1.01 KB,
patch
|
Fallen
:
review+
Fallen
:
approval-calendar-aurora+
Fallen
:
approval-calendar-beta+
|
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.
Updated•14 years ago
|
Comment 1•13 years ago
|
||
This was an idea I had a while back for this bug. I've got no idea if it'll work or not.
Assignee | ||
Comment 2•13 years ago
|
||
Why not just change install.rdf from
<em:maxVersion>@THUNDERBIRD_VERSION@</em:maxVersion>
to
<em:maxVersion>@THUNDERBIRD_VERSION@.*</em:maxVersion>
?
Reporter | ||
Comment 3•13 years ago
|
||
(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.*
Assignee | ||
Comment 4•13 years ago
|
||
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 5•13 years ago
|
||
Comment on attachment 627556 [details] [diff] [review]
fix for all branches
Not tried it, but looks good.
Attachment #627556 -
Flags: feedback?(mbanner) → feedback+
Updated•13 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Reporter | ||
Comment 6•13 years ago
|
||
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)
Assignee | ||
Comment 7•13 years ago
|
||
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.*?
Reporter | ||
Comment 8•13 years ago
|
||
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.
Reporter | ||
Comment 9•13 years ago
|
||
Oh as long we don't land this on comm-esr, it will also work for ESR releases.
Assignee | ||
Comment 10•13 years ago
|
||
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.
Reporter | ||
Comment 11•13 years ago
|
||
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+
Reporter | ||
Updated•13 years ago
|
Attachment #629881 -
Attachment is obsolete: true
Attachment #629881 -
Flags: review?(ssitter)
Attachment #629881 -
Flags: feedback?(mbanner)
Assignee | ||
Comment 12•13 years ago
|
||
Ok, I'll wait with check-in until macosx and win32 builders are back online to ensure it's working correctly.
Assignee | ||
Comment 13•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.8
Assignee | ||
Comment 14•13 years ago
|
||
Target Milestone: 1.8 → 1.7
Reporter | ||
Comment 15•13 years ago
|
||
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)
Reporter | ||
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 16•13 years ago
|
||
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.
Reporter | ||
Comment 17•13 years ago
|
||
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.
Comment 18•13 years ago
|
||
I believe fixing Bug 516026 - Ship SeaMonkey with integrated Lightning on as default would eliminate the need for this bug.
Reporter | ||
Comment 19•13 years ago
|
||
(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.
Reporter | ||
Comment 20•13 years ago
|
||
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+
Reporter | ||
Comment 21•13 years ago
|
||
Pushed to comm-central changeset 9c51b6b891ca
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Target Milestone: 1.7 → 1.9
Reporter | ||
Comment 22•13 years ago
|
||
Backported to releases/comm-aurora changeset 5bfe2d757514
Target Milestone: 1.9 → 1.8
Reporter | ||
Comment 23•13 years ago
|
||
Backported to releases/comm-beta changeset eab42b091d5d
Target Milestone: 1.8 → 1.7
You need to log in
before you can comment on or make changes to this bug.
Description
•