Closed Bug 607372 Opened 10 years ago Closed 9 years ago
automate nightly version bumping
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 188.8.131.52pre => 184.108.40.206pre 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.
Planning to fix this this quarter.
Assignee: nobody → bhearsum
Status: NEW → ASSIGNED
Priority: P4 → P3
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 #504693 - Flags: review? → review?(catlee)
Forgot to 'raise' after catching exceptions.
Sorry for the churn, I forgot to diff against the default branch
9 years ago
9 years ago
No longer blocks: 478420
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-
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 :(.
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
Closed: 9 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.