Open Stack

>> To clarify, the intent is definitely to keep a stabilization period
>> between the moment the branch is created and the "final" coordinated
>> release date.
>>
>> We currently do it by asking projects to release a "RC1" which coincides
>> with the branching, and then have them iterate on tagging further RCx
>> versions (usually just one). The last available version at coordinated
>> release date is re-tagged as a "normal" release number.
>>
>> With the unified model, projects would create the stabilization branch
>> when they feel like it, then iterate on tagging versions (usually just
>> one). The last available version at coordinated release date is
>> considered included in the "OpenStack" release, without the need for a
>> re-tag.
>>
>> Also to clarify, we are /already/ using that model for all
>> cycle-with-intermediary deliverables like Swift or Ironic or Karbor or
>> Vitrage or Monasca or CloudKitty or Horizon... It's not as if it was a
>> new thing that would break packagers workflows. They already support it.
> Can we at least enforce a rule that when tagging the "OpenStack" release, the
> y number should be increased? Bonus points for having the stabilization (RC)
> release use y=0, and the stable one starts from y=1.
>
> I know it may not sound to important for a computer, but it's useful for a
> human eye to know that the first release has a final 0 somewhere? (I really
> dislike the apache and mysql model in this regard)
>
> Ciao

One of the benefits of Thierry's proposal is it would eliminate the need
to retag the last release in order to get the final coordinated release
version. This would reintroduce the need to do that. So instead of
retagging something like 12.0.0.0rc2 to be 12.0.0, we would be retagging
12.0.0 to be 12.0.1.

If we think that is important, I would rather keep the RC designation on
those stabilization releases to make sure it's clear what is officially
ready, and what is in preparation to be deemed officially ready.

One other challenge I see with getting rid of RCs would be what would be
allowed to be merged. Only occasionally, but it does happen, we need to
merge something during the RC period that would be considered a breaking
change. We find a bug that requires reverting a patch that added a
config option. Or we need to fix a bug by changing the default value for
a config option. Or some other weird major change.

If we are strictly enforcing SemVer rules, that could mean that a
project could release a final end of cycle 12.0.0 release, then within a
week or two need to release a 13.0.0 release because of that one
breaking change. They are just numbers to convey what is included, so
it's not like that is not possible to do. But I think that could cause
confusion for downstream and potentially could cause issues with someone
picking up that 12.0.0 major release thinking it is legitimate, not
realizing that 13.0.0 is actually a fix for some issue in it.

Again, minor concerns, but something we should be aware of thinking
through how things would work.

Sean