With this more agile release cycle, can users expect minor releases to be
compatible with the previous release? Or will we still need to use the
RollingUpgrade path?
Regards,
Erik
On 10/20/14, 10:47 AM, "Tristan Tarrant" <ttarrant(a)redhat.com> 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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev