On Sep 18, 2014, at 5:08 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> David, > > What do you plan to do after branching in terms of merge-back and or > cherry-picking. We are discussing here (Schuberg-Philis + Rohit + Ian + > Wido (+ Sebastien)) that we would like to branch after getting master > stable and then when the real release work is underway branching of 4.5. > All new feature development in the meanwhile would have to go in its > respective branches until master is released again. > > thoughts, my dear RM? Yes, about we consider master the release branch and don't create a 4.5 branch. We declare feature freeze and we only take in bug fixes that need to come in through bugfix/hotfix branches that you merge. Folks developing features can do so on their own branch (that they can rebase on master right now), and they pull in the same bugfix/hotfix. This has the benefit of stabilizing master and getting it into a releasable state. Then when 4.5 is released, the features can be merged back and we can create a clean 4.6. Currently master is never releasable, and the effort going into our release branches don't all make it back to master. Hence all our releases are based on unstable work. As a community we don't currently have what it takes to run a QA effort to stabilize a release branch. We can switch that around, make our releases based on an already stable (released) branch and develop future features based on that released product. To re-iterate: *To make that switch we can delay 4.5, stabilize master (as if it where 4.5) with clean merging of bug fixes branches. Devs can bring in those same changes on their own branch to stay in sync with the stabilization process. *Once master is stable, we pretty much have our 4.5 but all other branches should have benefited from it. *We can then start creating 4.6 by merging the features that are ready *We then adopt a gitflow'esque model for patching master/4.5 and trickling all that down to all branches. *When 4.6 is ready we merge back into master…. *We get closer to a linear development model with the same confidence in each release. -sebastien > > On Thu, Sep 18, 2014 at 4:32 AM, David Nalley <da...@gnsa.us> wrote: > >> Hi folks, >> >> 4.3.1 is out the door now, so I am trying to get things lined up around >> 4.5.0. >> >> Please consider us in feature freeze right now - and my plan is to >> branch 4.5.0 this coming weekend. I'd like to see us hit code freeze >> by end of October. Right now, we have 4 blocker bugs and 63 critical >> bugs for the 4.5.0 release, so we have plenty to fix. >> >> If any of these elements cause you concern, please say so. >> >> --David >> > > > > -- > Daan
