[openstack-dev] [all] process problem with release tagging

Clark Boylan clark.boylan at gmail.com
Tue May 6 00:50:07 UTC 2014


On Mon, May 5, 2014 at 5:14 PM, John Dickinson <me at 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



More information about the OpenStack-dev mailing list