There is a difference between cherry picking and rebasing when it comes to reapply a work on top of a branch. Do you dislike both equally compared to a merge (aka railroad nexus git history approach)?
On 20 Oct 2014, at 16:47, Tristan Tarrant <[email protected]> wrote: > Hi guys, > > with the imminent release of 7.0.0.CR2 we are reaching the end of this > release cycle. There have been a ton of improvements (maybe too many) > and a lot of time has passed since the previous version (maybe to much). > Following up on my previous e-mail about future plans, here's a recap of > a plan which I believe will allow us to move at a much quicker pace: > > For the next minor releases I would like to suggest the following strategy: > - use a 3 month timebox where we strive to maintain master in an "always > releasable" state > - complex feature work will need to happen onto dedicated feature branches, > using the usual GitHub pull-request workflow > - only when a feature is complete (code, tests, docs, reviewed, CI-checked) > it will be merged back into master > - if a feature is running late it will be postponed to the following minor > release so as not to hinder other development > > I am also going to suggest dropping the cherry-picking approach and going > with git merge. In order to achieve this we need CI to be always in top form > with 0 failures in master. This will allow merging a PR directly from > GitHub's interface. We obviously need to trust our tools and our existing > code base. > > This is the plan for 7.1.0: > > 13 November 7.1.0.Alpha1 > 18 December 7.1.0.Beta1 > 15 January 7.1.0.CR1 > 30 January 7.1.0.Final > > > Tristan > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
