automate nightly version bumping

RESOLVED FIXED

Status

Release Engineering
General
P3
normal
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: bhearsum, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 7 obsolete attachments)

(Assignee)

Description

7 years ago
We currently have to manually bump the nightly version whenever we do a release. We should automate this. I think it's good enough to just bump the last number in the string and not try to deal with alpha -> beta or beta -> RC switches. Like this:
4.0a1pre -> 4.0a2pre
4.0b2pre -> 4.0b3pre
1.9.2.11pre => 1.9.2.12pre

One exception to the above is when we're doing RCs, the version number will be '4.0pre', and we should guard against bumping that to '4.1pre'. In those cases, we should not do any bumping at all.

There will still be a few situations in which we have to manually bump:
- Alpha -> Beta transitions (eg, 4.0a2pre -> 4.0b1pre)
- Beta -> RC transitions (eg. 4.0b9pre -> 4.0pre)
- RC -> first point release transitions (4.0pre -> 4.0.1pre)

It's not possible to know at tagging time if we need to do such a transition, though, so we're stuck doing them manually.
(Assignee)

Updated

7 years ago
Duplicate of this bug: 614245
(Assignee)

Comment 2

7 years ago
Planning to fix this this quarter.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: P4 → P3
(Assignee)

Comment 3

7 years ago
Created attachment 503597 [details] [diff] [review]
potential patch
(Assignee)

Comment 4

7 years ago
Created attachment 503989 [details] [diff] [review]
[needs more testing] different approach
(Assignee)

Comment 5

7 years ago
Created attachment 504534 [details] [diff] [review]
more tested patch, still needs a full run through of tagging
Attachment #503597 - Attachment is obsolete: true
Attachment #503989 - Attachment is obsolete: true
(Assignee)

Comment 6

7 years ago
Created attachment 504562 [details] [diff] [review]
v4
Attachment #504534 - Attachment is obsolete: true
(Assignee)

Comment 7

7 years ago
Created attachment 504693 [details] [diff] [review]
automatically bump nightly versions

Alright, this is finally ready for review. Summary of changes:
- Bump nightly versions
- Change util.hg.out to return rev+branch
- Key "--new-branch" in push through an explicit parameter
- Always push everything to the remote in apply_and_push
- Verify outgoing changes in tag-release.py
- Improved logging/output: Print Exceptions for anything that fails to tag
- Strip any local revisions if a repo fails
Attachment #504562 - Attachment is obsolete: true
Attachment #504693 - Flags: review?
(Assignee)

Updated

7 years ago
Attachment #504693 - Flags: review? → review?(catlee)
(Assignee)

Comment 8

7 years ago
Created attachment 504719 [details] [diff] [review]
raise exceptions after catching them

Forgot to 'raise' after catching exceptions.
Attachment #504693 - Attachment is obsolete: true
Attachment #504719 - Flags: review?(catlee)
Attachment #504693 - Flags: review?(catlee)
(Assignee)

Comment 9

7 years ago
Created attachment 504721 [details] [diff] [review]
correct diff

Sorry for the churn, I forgot to diff against the default branch
Attachment #504719 - Attachment is obsolete: true
Attachment #504721 - Flags: review?(catlee)
Attachment #504719 - Flags: review?(catlee)
Blocks: 627271
No longer blocks: 478420

Updated

7 years ago
Attachment #504721 - Flags: review?(catlee) → review+
(Assignee)

Comment 10

7 years ago
Comment on attachment 504721 [details] [diff] [review]
correct diff

Landed w/ some additional comments (requested by Catlee), and w/out the hgtags part.
Attachment #504721 - Flags: checked-in+
(Assignee)

Comment 11

7 years ago
Comment on attachment 504721 [details] [diff] [review]
correct diff

Had to back this out because I noticed that it failed to tag buildbot and compare-locales in staging.
Attachment #504721 - Flags: checked-in+ → checked-in-
(Assignee)

Comment 12

7 years ago
Created attachment 505941 [details] [diff] [review]
version that works with "otherReposToTag"

The problem with the last patch is that the "tagRepo" function claimed the otherReposToTag repositories were wrong, because they didn't have anything on a relbranch, and had an incorrect number of commits on "default". This version separates out tagging that uses a relbranch from otherReposToTag, which is probably how I should've written it in the first place. This way makes both scenarios easier/cleaner.

A meta-diff against my last patch should make this much easier to review.

Really sorry for all the churn here :(.
Attachment #504721 - Attachment is obsolete: true
Attachment #505941 - Flags: review?(catlee)

Updated

7 years ago
Attachment #505941 - Flags: review?(catlee) → review+
(Assignee)

Comment 13

7 years ago
Comment on attachment 505941 [details] [diff] [review]
version that works with "otherReposToTag"

Re-landed this today: changeset:   2105:22f8de68b385
Attachment #505941 - Flags: checked-in+
(Assignee)

Comment 14

7 years ago
All done here, *fingers crossed*.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 15

7 years ago
My assumption of "if it's bumped on the relbranch, it's bumped on default" here hasn't held true 100% of the time in the past. In this changeset we bumped the milestone on the relbranch for Fennec 4.0b2 from 2.0b8pre to 2.0b7pre: http://hg.mozilla.org/mozilla-central/rev/def2833dd2ac. From my digging, it looks like this happened by accident -- that we forgot to update the "milestone" in the mobile release config.

Based on that, and that nobody has been able to tell me why we would want to do a relbranch-only bump, or provide another example of when we did, I'm not going to worry about this. If it comes up again we can address it.
(In reply to comment #0)
> One exception to the above is when we're doing RCs, the version number will be
> '4.0pre', and we should guard against bumping that to '4.1pre'. In those cases,
> we should not do any bumping at all.

Did this happen ? If I take the just the code in lib/python/build/versions.py then I get
>>> nextVersion('4.0', pre=True)
'4.1pre'

Could be a problem if we do a 4.0 RC2 build1.
(Assignee)

Comment 17

7 years ago
(In reply to comment #16)
> (In reply to comment #0)
> > One exception to the above is when we're doing RCs, the version number will be
> > '4.0pre', and we should guard against bumping that to '4.1pre'. In those cases,
> > we should not do any bumping at all.
> 
> Did this happen ? If I take the just the code in lib/python/build/versions.py
> then I get
> >>> nextVersion('4.0', pre=True)
> '4.1pre'
> 
> Could be a problem if we do a 4.0 RC2 build1.

egads, good catch Nick! I'll file a follow-up on this.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.