[Gluster-Maintainers] Release scheduling and lifecycle of versions

Shyam srangana at redhat.com
Fri Jun 10 17:56:20 UTC 2016


On 06/09/2016 10:21 PM, Niels de Vos wrote:
> ## What we want to address
>
> 1. regular releases, predictable cycle for users and other projects
> 2. faster "go to market" with new features, receive feedback from users
> 3. stable version(s) for 'happily running, no risk' deployments
> 4. active releases can do monthly bugfix updates (see backport criteria)
>
>
> ## Results of several rounds of discussion
>
> It seems that a 3 month release cycle is the most attractive. Each
> alternating major release would be a Long-Term-Support (LTS) one, the
> others are short living versions for users that are eager to test out a
> new feature.
>
>
> ## Three stable/LTS versions, 1.5 years of bugfixes
>
>
> ## Two stable/LTS versions, 1 year of bugfixes
>

I prefer the 1 year of bugfixes.

The delta from the older proposal seems to be around how long an LTS is 
maintained, which was 2 years in the prior mails, and is 1 year now, 
with an LTS release every 6 months, and a 3 month non-LTS release.

This seems more controllable, than 3 non-lts releases followed by an lts 
release, where contents can start changing rapidly as we relax criteria 
for the non-lts release.


More information about the maintainers mailing list