Proposed Branching and Release Strategy

[Tim St Clair <ts...@redhat.com>]

Greetings! 

I've conversed with folks about the idea of having a more formalized release and branching strategy, such that others who are downstream can rely on certain version semantics when planning upgrades, etc.  This becomes doubly important as we start to trend towards a 1.0 release, and folks will depend heavily on it for their core infrastructure, and APIs (Frameworks, and EC).

Therefore, I wanted to propose a more formalized branching and release strategy, and see what others think.  I slightly modified this pattern from the Condor & Kernel projects, which have well established processes. 

------------------------------
Basic Idea: 

1.) Create 2 Main Branches (Stable/Devel-Master based)
2.) Devel releases are cadence/time based and lightly tested. 
3.) Stable series only accepts bug fixes.  Merge path for all bug fixes deemed worthy, are through the stable series up to master.    
4.) @ some point devel goes through a *hardning phase* and becomes the new stable.

------------------------------
Version Semantics: 

Major.Minor.Revision-PatchBuild

Major:
 - Compatibility breakage (usually protocol or api shift), or enough minors to justify change.
  
Minor:
 - Devel (Odd) - 1.1.x
 - Stable (Even) - 1.0.x

Revision:
 - Devel - Cadence # Some set of feature enhancements
 - Stable - Bug and security fixes only (Higher bar of entry)

PatchBuild:
 - Upstream - Whoops our bad, we found a bug or two
 - Downstream - Back-port build variant. 

------------------------------
Series/Branches:

Development Series - (Odd Minor #'s): 1.1.x
The development series branches/tags are cadence based, and come off of master.  All new features are added to master.  All bug fixes should be merged through the stable series into the master.  It should be ok to introduce destabilizing features from time to time, provided its agreed upon by a Sheppard. 

Stable Series - (Even Minor #'s): 1.0.x
Stable series should *only contain* bug fixes.  This way, downstream folks have a common understanding that behavior should be maintained.  Should downstream folks wish to back-port features, they can do that at their own risk.  Every release of the stable series has some measure of quality > then a +1.  E.g. running some clusters for a period of time (X), 

Transition from Devel-> Stable:
After some point, the development series needs to go through a hardening phase.  This could include static analysis + running on some production cluster for a period of time.  Folks typically plan the transition around a conference series in order to announce the cool new features.
------------------------------

-- 
Cheers,
Tim
Freedom, Features, Friends, First -> Fedora
https://fedoraproject.org/wiki/SIGs/bigdata