On 06/10/2016 07:51 AM, Niels de Vos wrote: > After several weeks of discussions on this list, in the weekly meeting > and ad-hoc IRC chats, I have come to the following understanding of the > release schedule, lifecyle and minor updates. > > ## 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 > > In dates and versions, this results in something like: > > 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.14 goes GA (2017-12) > 3.9: EOL when 3.10 goes GA (2016-12) > 3.10 [LTS]: EOL when 3.16 goes GA (2018-06) > 3.11: EOL when 3.12 goes GA (2017-06) > 3.12 [LTS]: EOL when 3.18 goes GA (2018-12) > 3.13: EOL when 3.13 goes GA > 3.14 [LTS]: EOL when 3.20 goes GA > > (one of the 3.x releases will be called 4.0, I do not want to predict > when that is ready and leave that up to the 4.0 team) > > And, 'visualized': > > ----. > 3.5 | > -----------. > 3.6 | > ------------------. > 3.7 | > ----------------------------------------------. > | 3.8 | > '------.------.---------------------------' > | 3.9 | > : '------+-----------------------------------------. > | 3.10 | > : : '------.------.---------------------------' > | 3.11 | > : : : '------+------------------------------------- > | 3.12 > : : : : '------.------.----------------------- > | 3.13 | > : : : : : '------+----------------------- > | 3.14 > : : : : : : '------.------.--------- > | 3.15 | > : : : : : : : '------+--------- > | 3.16 > : : : : : : : : '--------- > > 2016-06 : 2016-12 : 2017-06 : 2017-12 : 2018-06 > > 2016-09 2017-03 2017-09 2018-03 > > > ## 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
+1 > > (one of the 3.x releases will be called 4.0, I do not want to predict > when that is ready and leave that up to the 4.0 team) Most probably it'd be around 3.12ish as per my prediction. > > ----. > 3.5 | > -----------. > 3.6 | > ------------------. > 3.7 | > --------------------------------. > | 3.8 | > '------.------.-------------' > | 3.9 | > : '------+---------------------------. > | 3.10 | > : : '------.------.-------------' > | 3.11 | > : : : '------+---------------------------. > | 3.12 | > : : : : '------.------.-------------' > | 3.13 | > : : : : : '------+----------------------- > | 3.14 > : : : : : : '------.------.--------- > | 3.15 | > : : : : : : : '------+--------- > | 3.16 > : : : : : : : : '--------- > > 2016-06 : 2016-12 : 2017-06 : 2017-12 : 2018-06 > > 2016-09 2017-03 2017-09 2018-03 > > > 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. What would be the frequency of the z stream releases for LTS? Should we keep it flexible and decide based on the volume of incoming fixes? > > Any suggestions for modifications or clarification needed before this > can be transferred to a good looking webpage (by Amye?) on gluster.org? > > Thanks, > Niels > > > > _______________________________________________ > maintainers mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/maintainers > _______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
