Excerpts from John Garbutt's message of 2015-06-03 14:24:40 +0100: > On 3 June 2015 at 14:09, Thierry Carrez <thie...@openstack.org> wrote: > > John Garbutt wrote: > >> Given we are thinking Liberty is moving to semantic versioning, maybe > >> it could look like this: > >> * 12.0.1 (liberty-1) will have some features (hopefully), and will be a tag > >> * 12.0.2.dev1 is the first commit after 12.0.1 and does not get a tag > >> * 12.0.2.dev1234 would be the 1234th commit after 12.0.1 > >> * 12.0.2 (liberty-2) will also contain features > >> * 12.0.3 (liberty-3) is focused on priority features (given the current > >> plan) > >> * 12.1 is Liberty release is just bug fixes on 12.0.3 > >> * 13.0.0.dev1 would be the first commit to open M > > > > The current thinking on the release management team would be to do > > something like this for projects that are still doing milestone-based > > development: > > > > * 12.0.0b1 (liberty-1) > > * 12.0.0b2 (liberty-2) > > * 12.0.0b3 (liberty-3) > > * 12.0.0rc1 (RC1) > > * 12.0.0 is Liberty release > > > > I think assuming people can tell 12.0.1 is an alpha and 12.1 is a > > release that is just bug fixes over 12.0.3 is a bit crazy... > > We go to great lengths to ensure folks can upgrade from b1 -> b3 and > b2 -> release. I am really looking for a way to advertise that, incase > its useful. > > ... But it could/will be missing aligned docs and translations. So > maybe its not enough different from beta... needs more thought. > > > The alternative would be to go full intermediary releases and do: > > > > * 11.1.0 > > * 11.2.0 > > * 11.2.1 > > * 11.3.0 > > * 11.3.1 (oh! that happens to also be the "liberty" release!) > > * 11.4.0 > > > > I don't think we can maintain an middle ground. > > I think that could still work. > > But I was attempting to skip the exception of creating 11.2.1 just > because 11.2.0.dev42 fixes a critical bug present in 11.2.1. You would > have to wait for the next (time bound) release to get the extra bug > fixes and features.
If we don't assume stable branches for every tag, tags are pretty cheap in terms of maintenance. That's the appeal of using intermediate semver-based releases -- fixes get rolled out in the next release, whenever we want. I support moving nova to intermediate release, but not this cycle. We have a couple of smaller projects experimenting with it this cycle, and I think it would be a good idea for the nova team to wait until M to start that transition. That will give us time to figure out how to make that work well for applications (we're already doing it for libraries, and Swift, so I don't expect a *lot* of trouble, but still). Doug __________________________________________________________________________ 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