On Mon, May 5, 2014 at 5:14 PM, John Dickinson <m...@not.mn> wrote: > 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. > Going to defer to mordred on this, but isn't this a known problem with known fixes? > > 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. > I don't have all the answers, but I am pretty sure that the m-p branches are just a source of pain and don't really help us in our release process. Hoping to talk to ttx about this a bit more at the summit but the existence of the m-p branch introduces some weird interactions in the test infrastructure allowing for periods of time where we don't correctly test everything, then we release, cut the stable branch, start testing properly and hope that nothing broke during that time period. So I am a fan of removing these branches.
For not swift I think that means we cut the stable/foo branch instead of an m-p branch. For swift maybe we cut a stable/releaseversion branch or forgo it completely as you suggest. But going straight to stable makes a clear delineation between this is our release and any associated fixes backported from master and what master is. It will also open up master to development sooner in the dev cycle which may help things move along more quickly. > > 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 > Clark _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
