Open Stack

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

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

> [...]
> 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.

As far as Launchpad goes, I don't think switching to that model changes
anything. Oslo libraries (which also follow a semver-driven,
multiple-release + final one model) track features and bugfixes using
Launchpad alright, and the series graph in LP actually helps in figuring
out where you are. Together with the proposed changes in release
tracking to report after the fact more than try to predict (see thread I
posted yesterday), I think it would work just fine.

-- 
Thierry Carrez (ttx)