[Gluster-devel] Idea: Alternate Release process

Shyam srangana at redhat.com
Thu Jun 2 23:59:36 UTC 2016

On 05/29/2016 10:08 PM, Sankarshan Mukhopadhyay wrote:
> On Fri, May 20, 2016 at 7:30 PM, Shyam <srangana at redhat.com> wrote:
>> On 05/19/2016 10:25 PM, Pranith Kumar Karampuri wrote:
>>> Once every 3 months i.e. option 3 sounds good to me.
>> +1 from my end.
>> Every 2 months seems to be a bit too much, 4 months is still fine, but gives
>> us 1 in 3 to pick the LTS, I like 1:4 odds better for the LTS, hence the 3
>> months (or 'alternative 2').
> It would perhaps be worthwhile to extend this release timeline/cadence
> discussion into (a) End-of-Life definition and invocation (b) whether
> a 'long term support' (assuming that is what LTS is) is of essentially
> any value to users of GlusterFS.

I see it as a couple of things here,
- We call one of the intermediate 3 month updates an LTS based on its 
stability and quality. This should provide a clean upgrade from the 
previous upgrade (as clean as possible at least, and should/could be a 
gating factor).

- The use of "one of the" above, is explicit so that we continue the 3 
month cadence on update releases, but say the 4th update does not make 
the cut then the 5th can, hence have the flexibility on the LTS

Unless we want to be extremely stringent on this.

Next, I would expect that this [1] page would be updated with this 
decision, either as soon as 3.8 is released or earlier than that.

> (b) especially can be (and perhaps should be) addressed by predictable
> and tested upgrade paths to ensure that users are able to get to newer
> releases without much hassles.

[1] http://www.gluster.org/community/release-schedule/

More information about the Gluster-devel mailing list