Open Stack

On 3 June 2015 at 15:22, Doug Hellmann <doug at doughellmann.com> wrote:
> 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.

True, and I like that.

I think not having a stable branch has upgrade implications. People on
one stable branch probably expect a smooth upgrade to the next one. So
the stable branches define the N and N+1 in our upgrade story, I
think.

> I support moving nova to intermediate release, but not this cycle.

+1

My main motivation here is actually making it clear how useful a
milestone release can be to get access to a feature you really, really
need much more quickly.

Its a shame its called a "beta", because I think the milestones are
more (production) useful than that. On the other had, they are also
worse than many "betas" you get (in terms of completed translations
and docs, etc). So maybe thats still the best label for the
milestones.

> 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).

Agreed. I am looking closely at how it works for ironic.

Thanks,
John