Open Stack

tl;dr: (1) the current tag names used don't work and we need
something else. (2) Swift (at least) needs to burn a
release number with a new tag

The current process of release is:

1) branch milestone-proposed (hereafter, m-p) from master
2) tag m-p with an RC tag (eg 1.13.1.rc1)
    * note that since there are no commits on m-p,
      this tag is an ancestor of master (effectively on master itself)
3) continue development on master
3.1) backport any changes necessary to m-p
4) after QA, tag m-p with the final version
5) merge m-p into master, thus making the final version tag
   an ancestor of master[0]


This process has 2 flaws:

First (and easiest to fix), the rc tag name sorts after the final
release name (`dpkg --compare-versions 1.13.1.rc1.25 lt 1.13.1`
fails). The practical result is that if someone grabbed a version of
the repo after m-p was created but before the merge and then packaged
and deployed it, their currently-installed version actually sorts
newer than the current version on master[1]. The short-term fix is to
burn a version number to get a newer version on master. The long-term
fix is to use a different template for creating the RC tags on m-p.
For example, `dpkg --compare-versions 1.13.1~rc1.25 lt 1.13.1` works.

Second, the process creates a time window where the version number on
master is incorrect. There are a few ways I'd propose to fix this. One
way is to stop using post-release versioning. Set the version number
in a string in the code when development starts so that the first
commit after a release (or creation of m-p) is the version number for
the next release. I'm not a particular fan of this, but it is the way
we used to do things and it does work.

Another option would be to not tag a release until the m-p branch
actually is merged to master. This would eliminate any windows of
wrong versions and keep master always deployable (all tags, except
security backports, would be on master). Another option would be to do
away with the m-p branch altogether and only create it if there is a
patch needed after the RC period starts.

The general idea of keeping release tags on the master branch would
help enable deployers (ie ops) who are tracking master and not just
releasing the distro-packaged versions. We know that some of the
largest and loudest OpenStack deployers are proud that they "follow
master".

What other options are there?


[0] This is the process for Swift, but in both Keystone and Ceilometer
    I don't see any merge commits from m-p back to master. This
    actually means that for Keystone and Ceilometer, any deployer
    packaging master will get bitten by the same issue we've seen in
    the Swift community.
[1] In Icehouse, this window of opportunity was exacerbated by the
    long time (2 weeks?) it took to get m-p merged back into master.



--John



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140505/f164ada0/attachment.pgp>