bhearsum@mozilla.com (:bhearsum) Assignee
	Description • 14 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.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 2 • 14 years ago

Planning to fix this this quarter.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 7 • 14 years ago

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

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 8 • 14 years ago

Forgot to 'raise' after catching exceptions.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 9 • 14 years ago

Sorry for the churn, I forgot to diff against the default branch

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 10 • 14 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.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 11 • 14 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.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 12 • 14 years ago

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

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 13 • 14 years ago

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

Re-landed this today: changeset:   2105:22f8de68b385

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 14 • 14 years ago

All done here, *fingers crossed*.

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 15 • 14 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.

	Nick Thomas [:nthomas] (UTC+12)
	Comment 16 • 14 years ago

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

	bhearsum@mozilla.com (:bhearsum) Assignee
	Comment 17 • 14 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.