Sean McGinnis <sean.mcgin...@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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
