Open Stack

Excerpts from John Garbutt's message of 2015-06-03 14:24:40 +0100:
> On 3 June 2015 at 14:09, Thierry Carrez <thierry at 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