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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev