The default bug view has changed. See this FAQ.

Automate setting minversion/maxversion for release builds

RESOLVED FIXED in 1.7

Status

Calendar
Build Config
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Fallen, Assigned: Stefan Sitter)

Tracking

unspecified

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

6 years ago
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
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.
(Assignee)

Comment 2

5 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

5 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

5 years ago
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.*
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
(Reporter)

Comment 6

5 years ago
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.
Attachment #629881 - Flags: review?(ssitter)
Attachment #629881 - Flags: feedback?(mbanner)
(Assignee)

Comment 7

5 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

5 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

5 years ago
Oh as long we don't land this on comm-esr, it will also work for ESR releases.
(Assignee)

Comment 10

5 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

5 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

5 years ago
Attachment #629881 - Attachment is obsolete: true
Attachment #629881 - Flags: review?(ssitter)
Attachment #629881 - Flags: feedback?(mbanner)
(Assignee)

Comment 12

5 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

5 years ago
Pushed to https://hg.mozilla.org/comm-central/rev/9ccbefb9df5e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.8
(Assignee)

Comment 14

5 years ago
Pushed to https://hg.mozilla.org/releases/comm-aurora/rev/39e98d760147
Target Milestone: 1.8 → 1.7
(Reporter)

Comment 15

5 years ago
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.
Attachment #644614 - Flags: review?(ssitter)
(Reporter)

Updated

5 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 16

5 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

5 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

5 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

5 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

5 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

5 years ago
Pushed to comm-central changeset 9c51b6b891ca
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: 1.7 → 1.9
(Reporter)

Comment 22

5 years ago
Backported to releases/comm-aurora changeset 5bfe2d757514
Target Milestone: 1.9 → 1.8
(Reporter)

Comment 23

5 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.