<top post> I vote for this. How do we ensure that all following releases are made on schedule? </top post>
----- Original Message ----- > From: "Vijay Bellur" <[email protected]> > To: "Niels de Vos" <[email protected]> > Cc: "GlusterFS Maintainers" <[email protected]> > Sent: Friday, June 10, 2016 10:37:33 PM > Subject: Re: [Gluster-Maintainers] Release scheduling and lifecycle of > versions > > On Thu, Jun 9, 2016 at 10:21 PM, Niels de Vos <[email protected]> wrote: > > ## Two stable/LTS versions, 1 year of bugfixes > > > > Looking at the diagram makes me wonder if this really is a sane approach > > that we can promise to our users. When 3.13 (or 4.x) gets released, we > > would have 4 active versions. At the moment we are already struggling > > with three active versions, so I doubt we can really do that. So, here a > > variation, and my suggestion to keep two stable releases instead of > > three: > > > > 3.5: EOL when 3.8 goes GA (2016-06) > > 3.6: EOL when 3.9 goes GA (2016-09) > > 3.7: EOL when 3.10 goes GA (2016-12) > > 3.8 [LTS]: EOL when 3.12 goes GA (2017-06) > > 3.9: EOL when 3.10 goes GA (2016-12) > > 3.10 [LTS]: EOL when 3.14 goes GA (2017-12) > > 3.11: EOL when 3.12 goes GA (2017-06) > > 3.12 [LTS]: EOL when 3.16 goes GA (2018-06) > > 3.13: EOL when 3.13 goes GA > > 3.14 [LTS]: EOL when 3.18 goes GA > > > > This seems like a good plan to me. > > > > > Providing bugfixes for a LTS release for a year seems like a suitable > > middle road. If other projects/organizations want to support a certain > > version longer, they can do so themselves or step up and contribute a > > maintainer to our community. > > > > > > I expect that the number of patches in the stable releases get reduced A > > LOT compared to the current 3.7 version. With regular releases there > > should not be a need to backport complex patches or features. > > Maintainance of a stable release should be a very boring and simple > > task. > > +1 > > > > > Any suggestions for modifications or clarification needed before this > > can be transferred to a good looking webpage (by Amye?) on gluster.org? > > > > A post on -devel and -users explaining this release cadence/strategy > and soliciting feedback would be necessary before we publish on > gluster.org. > > -Vijay > _______________________________________________ > maintainers mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/maintainers > _______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
