Open Stack

Excerpts from Thierry Carrez's message of 2015-09-21 10:26:58 +0200:
> Boris Pavlovic wrote:
> > The main idea is next: 
> > *) Master branch will be used for new major Rally versions development
> > e.g. 0.x.y -> 0.x+1.0 switch
> >    that can include not backward compatible changes. 
> 
> You mean x.y.0 -> x+1.0.0, right ?
> 
> > *) Latest version - we will port plugins, bug fixes and part of features
> > to it
> > *) Stable version - we will port only high & critical bug fixes if it is
> > possible 
> 
> So... this is pretty close from what we're doing elsewhere in OpenStack,
> except that we do:
> 
> Feature branches: not backward compatible changes
> Master: bug fixes, backward-compatible features, release regularly
> Stable: High/Critical bugfixes backports, release on-demand
> 
> The only difference with your model is how you split feature development
> between master and feature branches. In your model you do most of the
> feature development in the experimental branch (master) and port pieces
> of it in the release branch (latest). In our case only the
> backward-incompatible work lands in the experimental branch (feature/*),
> and the release branch (master) contains everything else.
> 
> I am just not sure it's different enough to justify being different :)
> 

I agree. The Oslo team releases as often as every week, and uses feature
branches for ongoing work like the zmq driver that shouldn't land
partially completed. Other teams that use feature branches and release
less frequently (neutron is one I can think of off the top of my head
from liberty, but there have been others in the past).

Parts of our CI system relies on this model being the same for all
projects. For example, testing source versions of projects (rather
than packaged versions) together works much much better if they are
on the same branch, since the fallback for a missing branch is to
use the 'master' branch. That means feature branches in one project can
be tested against master in another automatically. The release tools
also make some assumptions about the main release development work
happening on master instead of a separate release branch.

I'm concerned about the amount of tooling changes we would need to
implement in order to support one project being different in this
way.  Can you elaborate on how the current system won't meet your
needs?

Doug