Open Stack

Excerpts from Thierry Carrez's message of 2015-05-29 12:12:51 +0200:
> Devananda van der Veen wrote:
> > [...]
> > The alternative we discussed:
> > - use feature branches for risky / large work, keeping total # of
> > branches small, and rebasing them regularly on master
> > - keep trunk moving quickly for smaller / less risky / refactoring changes
> > - "slow down" for a week or two before a release, but dont actually
> > freeze master
> > - cut releases when new features are available
> > - OpenStack coordinated releases are taken from latest independent release
> > - that release will then get backports & stable maintenance, other
> > independent releases don't

That last part is important -- you don't want to get bogged down with
managing umpteen different backports, so you want to maintain one stable
branch per cycle. Deployers running from master will get new stuff and
fixes quickly, and deployers running from stable releases will have
stability and fixes. We'll be serving both types of downstream consumers
well.

> 
> With the already-mentioned caveats on feature branch usage, I think this
> makes sense, for simpler or more stable projects that can actually
> release something that works without a large "stabilization" period.
> 
> That said, it's worth noting that the way Swift currently aligns with
> the coordinated release at the end of a cycle is a little different:
> 
> - for intermediary releases, Swift would just soft-freeze at a proposed
> SHA and tag that if everyone is fine with it after some time (which is
> what you propose here)
> 
> - for the "final" release Swift tags a RC1 (which triggers a
> stable/$SERIES release branch) and has the option of doing other RCs if
> a critical issue is found before the coordinated release date, then the
> final is re-tagged from the last RC
> 
> In all cases, for stable maintenance/CI reasons, we need to cut a
> stable/$SERIES branch for every project in the weeks preceding the
> "coordinated release" date -- but I guess we have two options there.
> 
> (1) we could adopt the Swift RC model and special-case the release
> process for the "final" release.
> 
> (2) we could just create the stable branch from your presumed last
> release, and in case a critical issue is found, backport the fix and tag
> a point release there (and consider that point release the "$SERIES
> release")
> 
> Since I would only recommend simpler / more stable projects to switch to
> that model for the time being (projects that are less likely to need
> "release candidates"), I think (2) makes sense (and I could see Swift
> adopting it as well).

If I understand you correctly, option 2 is what we do for Oslo
libraries that release this way.

> > [...]
> > Before Ironic actually makes the switch, I would like us to discuss
> > and document the approach we're going to take more fully, and get
> > input from other teams on this approach. Often, the devil is in the
> > details - and, for instance, I don't yet understand how we'll fit this
> > approach into SemVer, or how this will affect our use of launchpad to
> > track features (maybe it means we stop doing that?).
> 
> As far as semver goes, since you switch to independent releases you
> can't stick to a common ("2015.1.0") version anyway, so I think it's
> less confusing to use a semver versioning than using conflicting
> date-based ones.

I have a todo on my list to write up a spec summarizing the summit
discussion on the new version numbering scheme for all projects.
tl;dr is moving to semver, starting with version 12.0.0 (since Kilo
was our 11th release).

Doug