Open Stack

Sean McGinnis <sean.mcginnis at gmx.com> writes:

> During the Stein PTG in Denver, the release management team talked about ways
> we can make things simpler and reduce the "paper pushing" work that all teams
> need to do right now. One topic that came up was the usefulness of pushing tags
> around milestones during the cycle.
>
> There were a couple of needs identified for doing such "milestone releases":
>     1) It tests the release automation machinery to identify problems before
>        the RC and final release crunch time.
>     2) It creates a nice cadence throughout the cycle to help teams stay on
>        track and focus on the right things for each phase of the cycle.
>     3) It gives us an indication that teams are healthy, active, and planning
>        to include their components in the final release.
>
> One of the big motivators in the past was also to have output that downstream
> distros and users could pick up for testing and early packaging. Based on our
> admittedly anecdotal small sample, it doesn't appear this is actually a big
> need, so we propose to stop tagging milestone releases for the
> cycle-with-milestone projects.

One of the issues that was raised from downstream consumers [1] is that
this complicates upgrade testing using packages, since tools like yum
will think that the stable branch (with a final version tag) has a
higher version number than master (with a dev version computed off of
the first release candidate where the stable branch was created).

We've discussed this problem in the past and not done anything because
the downstream folks were always able to live with the gap until the
first milestone. Now that we're unlikely to have milestone tags for most
projects, the gap will extend to the length of the cycle, blocking
upgrade testing until the release candidates are tagged, shortly before
we're ready to release. They could guess at the next version numbers,
but if they guess wrong they would be left with invalid packages and
have to do a bunch of testing work again. It's better for us to provide
authoritative information about version changes upstream.

We need all projects to increment their version at least by one minor
version at the start of each cycle to save space for patch releases on
the stable branch, so we looked at a few options for triggering that
update automatically.

One option is to add a tag, like an alpha. This is somewhat appealing
because the release team can just do it without anyone on the project
teams having to worry about it. However, I don't particularly like this
option for two reasons. First, the release team would have to monitor
the work in each project and wait for some patch to land after the fork,
so we could tag that (otherwise the branch would get the new version,
too). More importantly, the tag would trigger a release, and I don't
think we want to publish artifacts just to tweak the version
calculation.

A similarly low impact solution is to use pbr's Sem-Ver calculation
feature and inject patches into master to bump the version being
computed by 1 feature level (which should move from x.y.z.0rc1 to
somethinglike x.y+1.0.devN). See [2] for details about how this works.

This is the approach I prefer, and I have a patch to the branching
scripts to add the Sem-Ver instruction to the patches we already
generate to update reno [3].

That change should take care of our transition from Stein->T, but we're
left with versions in Stein that are lower than Rocky right now. So, as
a one time operation, Sean is going to propose empty patches with the
Sem-Ver instruction in the commit message to all of the repositories for
Stein deliverables that have stable/rocky branches.

Let us know if you have any questions.

Doug


[1] http://lists.openstack.org/pipermail/openstack-operators/2018-October/015991.html
[2] https://docs.openstack.org/pbr/latest/user/features.html#version 
[3] https://review.openstack.org/#/c/609827/