Hi, You could just bump the major version for the first release of the new year - in this case, we would make 2.6 be 3.0. It achieves the same objective without having a big discontinuity in the release numbers.
Thanks, Dave. On 12/15/2015 08:37 AM, O'Driscoll, Tim wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon >> Sent: Sunday, December 13, 2015 7:23 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] releases scheduling >> >> Hi all, >> >> We need to define the deadlines for the next releases. >> During 2015, we were doing a release every 4 months. >> If we keep the same pace, the next releases would be: >> 2.3: end of March >> 2.4: end of July >> 2.5: end of November >> >> However, things move fast and it may be a bit long to wait 4 months for >> a feature. That's why I suggest to progressively shorten release terms: >> 2.3: end of March >> 2.4: mid July >> 2.5: end of October >> and continue with a release every 3 months: >> 2.6: end of January >> 2.7: end of April >> 2.8: end of July >> This planning would preserve some of the major holiday periods >> (February, May, August, December). >> >> The first period, for the first submission of a feature, was 2 months >> long. >> Then we had 2 other months to discuss, merge and fix. >> We should shorten only the first period. >> >> Anyway, the next deadlines should be unchanged: >> - January 31: end of first submission phase >> - March 31: release 2.3 >> >> Opinions are welcome. > > I think moving to quarterly releases is a good idea. Your proposal to do this > in a gradual way, so that we don't change the 2.3 dates, also makes sense. > > Should we consider changing the release numbering at the same time? It's > difficult to keep track of when each 2.x release is due, and we don't have > any criteria in place for moving to 3.x in future. Many people like the > Ubuntu numbering scheme of Year.Month. Should we consider adopting that > convention? If we move in future to a model where we have long-term support > releases (something that was touched on in Dublin), then we could append an > LTS designation to the release number. > > > Tim > -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338
