[infinispan-dev] Infinispan 7.1 plan

[Erik Salter]

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 at 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 at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/infinispan-dev