705028 - improve version numbers: update release process, merge stabilization branch to trunk

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Brian Warner [:warner :bwarner]]

Once the discussion in http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/b10376ad384568ee comes to a consensus, the next steps in improving our handling of version numbers will be:

* merge from the stabilization and/or release branches into trunk. This doesn't actually need to change code on trunk (i.e. --strategy=ours, or --no-commit followed by manual examination of code to avoid changing min/maxVersion is fine). The important thing is to let git know that trunk inherits from recent release tags, so it can count version numbers from e.g. 1.3 instead of 0.9 (which is the latest tag reachable from master).
* decide on how to manage minVersion/maxVersion
* update the instructions in https://wiki.mozilla.org/Jetpack/Release_Process#Spin_Test_Builds to remove the "modify .version" steps, and figure out the right order of operations (probably tag before archive) to get the versions updated properly

Comment 1

[Brian Warner [:warner :bwarner]]

Mossop made a good point today: instead of merging back into trunk, we could just add a tag to trunk (just after we update the stabilization branch for the next release, e.g. as we're doing today for 1.4), with a name like "1.5-dev". This would cause all trunk revisions to get a version string like "1.5-dev-NUMPATCHES-gREVID", and would indicate that anything landing on trunk is destined for 1.5 .

That's probably the most useful sort of string to put on trunk revisions.

Comment 2

[Myk Melez [:myk] [@mykmelez]]

I like this idea and have added the 1.5-dev tag to master:

https://github.com/mozilla/addon-sdk/tree/1.5-dev

Thus we can try out this idea and iterate as needed.

The Release Process doc still needs updating, not only the Spin Test Builds section but also the Merge Master To Stabilization section.

Comment 3

[Brian Warner [:warner :bwarner]]

oh, one quirk that I just noticed: the stabilization branch now has the
1.5-dev tag in its ancestry. I'm guessing that you correctly made the -dev
tag *after* doing the master->stabilization merge, but that since there were
no additional revisions added to master after the merge, master was still
sitting on the now-common-ancestor.

As a result, all revisions on the stabilization branch (until you create the
1.4a1 tag) will describe themselves as as 1.5-dev-SOMETHING, whereas
1.4-dev-SOMETHING would be more accurate. Not a big deal.

To correct it in the future, we should either wait to apply the -dev tag
until after something has changed on master, or we should apply a dummy
commit (git commit --allow-empty -m "starting development for 1.5") after
doing the merge, and then tag *that*.

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Brian, what still needs to be done here, aside from updating the doc?

Comment 5

[Brian Warner [:warner :bwarner]]

I think this is mostly done. The Release Process doc has one remaining section that needs editing (and already has a "Check With Brian" comment).

Tomorrow I'm going to make a draft "How To Do A Hot-Fix Release" checklist, and move that remaining section into it, then remove that section from the normal release process. Then I think we'll be able to close this ticket.

Comment 6

[Brian Warner [:warner :bwarner]]

I've started writing this up on https://jetpack.etherpad.mozilla.org/hotfix-process

Comment 7

[Brian Warner [:warner :bwarner]]

Ok, I removed the obsolete section from the Release Process document, and added a section on hotfixes (https://wiki.mozilla.org/Jetpack/Release_Process#Panic). It needs editing and cleanup but I think it's good enough to close this ticket.