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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev