I don't really like this plan.0.9.x 0.10.x both sound great.
But if we call HA 0.11.x what version do we put on master? If it is 0.12 it 
implies that 0.11 was released, even just as a preview, with HA and 0.12 is 
potentially a regression because there is no HA yet. If it is 0.11 then that is 
just really confusing.

If we are going to have a 0.10 branch that we will continue to be supported for 
stability, lets just merge HA into master. 

If we think HA is going to take longer to stabilize than the 0.11 time frame 
then lets create a HA feature branch that is not tied to a release number.  I 
personally don't think it will take that long to stabilize HA.
- Bobby
 


     On Friday, March 20, 2015 4:29 PM, P. Taylor Goetz <ptgo...@gmail.com> 
wrote:
   

 In order to allow work to continue on the master branch while we move closer 
to a 0.10.0 release, I’ve created the following branches:

0.9.x-branch (maintenance branch)
  * Should be inactive unless important fixes are discovered.
  * Changes should be cherry-picked from master unless specific to 0.9.x

0.10.x-branch (security branch)
  * Active branch for 0.10.0 release.
  * Changes should be cherry-picked from master to be included in the release 
(e.g. STORM-714, STORM-617)

0.11.x-branch (Nimbus HA branch)
  * Should be up merged to master when master changes.


I’m not very excited about having to keep 0.11.x in sync with master, but I 
think the Nimbus HA work needs as many eyes and as much testing as possible. 
Having a dedicated branch will make it easier to create preview releases and 
allow users to kick the tires. It will also ease some of the burden on Parth 
who’s spent a lot of time keeping that work upmerged.

If anyone has any questions, concerns or suggestions regarding branch/release 
management, let me know.

-Taylor


  

Reply via email to