automate nightly version bumping

RESOLVED FIXED

Status

P3
normal
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: bhearsum, Assigned: bhearsum)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 7 obsolete attachments)

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.
Duplicate of this bug: 614245
Planning to fix this this quarter.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: P4 → P3
Created attachment 503989 [details] [diff] [review]
[needs more testing] different approach
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
Created attachment 504562 [details] [diff] [review]
v4
Attachment #504534 - Attachment is obsolete: true
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?
Attachment #504693 - Flags: review? → review?(catlee)
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)
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)
Attachment #504721 - Flags: review?(catlee) → review+
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+
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-
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)
Attachment #505941 - Flags: review?(catlee) → review+
Comment on attachment 505941 [details] [diff] [review]
version that works with "otherReposToTag"

Re-landed this today: changeset:   2105:22f8de68b385
Attachment #505941 - Flags: checked-in+
All done here, *fingers crossed*.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
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.
(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.