Open Stack

Robert Collins wrote:
> [...]
> Here's what happens.
> 
> The two interacting rules are this:
>  - pbr will now error if it tries to create a version number lower
> than the last release (and releases are found via the git tags in the
> branch).
>  - pbr treats preversion version numbers as a hard target it has to use
> 
> When we make a release (say 2014.1.0), we tag it, and we now have
> setup.cfg containing that version, and that version tagged.
> 
> The very next patch will be one patch *after* that version, so it has
> to be a patch for the next release. That makes the minimum legitimate
> release version 2014.1.1, and the local version number will be a dev
> build so 2014.1.1.dev1.g$shahere.
> 
> But the target it is required to use is 2014.1.0 - so we get a dev
> build of that (2014.1.0.dev1.g$shahere) - and thats lower than the
> last release (2014.1.0) and thus we trigger the error.
> 
> So, if we tag an API server branch with the same version it has in the
> branch, any patch that attempts to change that branch will fail,
> unless that patch is updating the version number in setup.cfg.

I think the current release process already enforces that (that the
patch after the tag is the setup.cfg version bump). That was the only
way to avoid building erroneous versions (2014.1.0.dev1 after 2014.1.0).
Here is what we do currently (say for Icehouse release):

At RC1 time on master branch, a patch is pushed to bump setup.cfg to
2014.2 (a.k.a. "open Juno development"). On master, future tags will be
2014.2.b1 etc.

A release branch (proposed/icehouse) is created from the last commit
before that version bump. That branch still has 2014.1 in setup.cfg, and
we control what lands on it. At release time, we tag 2014.1.0 on
proposed/icehouse. The very next commit on that branch is a version bump
on setup.cfg to go to 2014.1.1. The future tag on that branch will be
2014.1.1.

If I understand the issue correctly, that process will just continue to
work.

For details, see:
https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release#Final_release
in particular the "Push new version to master" and "Push .1 version to
stable/$SERIES branch" sections.

> [...]
> Going forward:
> 
> * We could just do the above - tag and submit a version fix
> 
> * We could submit the version fix as soon as the release sha is
> chosen, before the tag
>   - we could also wait for the version fixes to land before tagging
> 
> * We could change pbr to not enforce this check again
>   - or we could add an option to say 'I don't care'
> 
> * We could remove the version numbers from setup.cfg entirely
> 
> * We could change pbr to treat preversion versions as a *minimum*
> rather than a *must-reach*.
> 
> I'm in favour of the last of those options. Its quite a conceptual
> change from the current definition, which is why we didn't do it
> initially. The way it would work is that when pbr calculates the
> minimum acceptable version based on the tags and sem-ver: headers in
> git history, it would compare the result to the preversion version,
> and if the preversion version is higher, take that. The impact would
> be that if someone lands an ABI break on a stable-release branch, the
> major version would have to be bumped - and for API servers we don't
> want that. *but* thats something we should improve in pbr anyway -
> teach it how we map semver onto the API server projects [e.g. that
> major is the first two components of 2014.1.0, and minor and patch are
> bundled together into the third component.
> 
> The reason I prefer the last option over the second last, is that we
> don't have any mechanism to skip versions other than tagging today -
> and doing an alpha-0 tag at the opening of a new cycle just feels a
> little odd to me.

If my analysis above is right, I don't think we need to change anything:
the issue in pbr is only triggered if you try to do something you should
not do (i.e. have setup.cfg <= tag on non-tagged commits).

Let me know what you think,

-- 
Thierry Carrez (ttx)