[Gluster-Maintainers] Release scheduling and lifecycle of versions
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