Open Stack

On Thursday, 11 June 2020 12:23:27 CEST Thierry Carrez wrote:
> Mark Goddard wrote:
> >> [Excerpt from Thierry's original post yesterday...]
> >> 
> >>>> The "final" release would be marked by creating a release
> >>>> (stable) branch, and that would need to be done before a
> >>>> deadline. Like today, that deadline depends on whether that
> >>>> deliverable is a library, a client library, a release-trailing
> >>>> exception or just a regular part of the common release.
> >>>> 
> >>>> The main change this proposal introduces would be to stop having
> >>>> release candidates at the end of the cycle. Instead we would
> >>>> produce a release, which would be a candidate for inclusion in
> >>>> the coordinated OpenStack release.
> >> 
> >> For service projects, that "deadline" he talks about would be the
> >> start of the traditional RC period, we just wouldn't use special rc1
> >> tags for branching at that point, we'd use actual version numbers to
> >> branch from. I think the proposal has probably confused some folks
> >> by saying, "stop having release candidates [...and instead have a]
> >> candidate for inclusion in the coordinated OpenStack release." It
> >> would basically still be a "release candidate" in spirit, just not
> >> in name, and not using the same tagging scheme as we have
> >> traditionally used for release candidates of service projects.
> > 
> > I think this is reading between the lines somewhat. I agree that it
> > makes sense however, and preserves the period before release during
> > which every deliverable to be included in GA should have a release
> > available.
> 
> 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
-- 
Luigi