Open Stack

Steven Hardy wrote:
> The obvious answer is a stable branch for certain TripleO components, and
> in particular for t-h-t, but this has disadvantages if we take the
> OpenStack wide "no feature backports" approach - for example "upgrade
> support to liberty" could be considered a feature, and many other TripleO
> "features" are really more about making features of the deployed OpenStack
> services consumable.
> 
> I'd like propose we take a somewhat modified "release branch" approach,
> which combines many of the advantages of the stable-branch model, but
> allows for a somewhat more liberal approach to backports, where most things
> are considered valid backports provided they work with the currently
> released OpenStack services (e.g right now, a t-h-t release/kilo branch
> would have to maintain compatibility with a kilo Heat in the undercloud)

I think that makes sense.

The critical point being they should *not* be named stable/$SERIES
(which kind of indicates that you follow the stable branch policy), but
something else. release/$SERIES is slightly tainted (used to be the name
of the pre-release branches we created during RCs before release) but I
don't really have better suggestions (deploy/$SERIES ? support/$SERIES ?).

I agree with James that you'll need to clearly describe such branch
policy (everything should be backported ? everything can be backported ?
Only specific things can be backported ?) so that everyone is on the
same page.

Cheers,

-- 
Thierry Carrez (ttx)