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
