688719 - Automate setting minversion/maxversion for release builds

Status: RESOLVED FIXED

(Calendar :: Build Config, defect)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 1

[Mark Banner (:standard8)]

Attachment: 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.

Comment 2

[Stefan Sitter [:ssitter]]

Why not just change install.rdf from
    <em:maxVersion>@THUNDERBIRD_VERSION@</em:maxVersion>
to
    <em:maxVersion>@THUNDERBIRD_VERSION@.*</em:maxVersion>
?

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(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.*

Comment 4

[Stefan Sitter [:ssitter]]

Attachment: 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 5

[Mark Banner (:standard8)]

Comment on attachment 627556 [details] [diff] [review]
fix for all branches

Not tried it, but looks good.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: 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.

Comment 7

[Stefan Sitter [:ssitter]]

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.*?

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Oh as long we don't land this on comm-esr, it will also work for ESR releases.

Comment 10

[Stefan Sitter [:ssitter]]

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 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 12

[Stefan Sitter [:ssitter]]

Ok, I'll wait with check-in until macosx and win32 builders are back online to ensure it's working correctly.

Comment 13

[Stefan Sitter [:ssitter]]

Pushed to https://hg.mozilla.org/comm-central/rev/9ccbefb9df5e

Comment 14

[Stefan Sitter [:ssitter]]

Pushed to https://hg.mozilla.org/releases/comm-aurora/rev/39e98d760147

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: 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.

Comment 16

[Stefan Sitter [:ssitter]]

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.

Comment 17

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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

[Worcester12345]

I believe fixing Bug 516026 - Ship SeaMonkey with integrated Lightning on as default would eliminate the need for this bug.

Comment 19

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(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 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 21

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central changeset 9c51b6b891ca

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Backported to releases/comm-aurora changeset 5bfe2d757514

Comment 23

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Backported to releases/comm-beta changeset eab42b091d5d