[Gluster-devel] Idea: Alternate Release process
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
- 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  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.
More information about the Gluster-devel