On 12/15/15, 1:15 PM, "dev on behalf of Dave Neary" <dev-bounces at dpdk.org on behalf of dneary at redhat.com> wrote:
>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. I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of when a release was done. Trying to remember when 3.4 or even 1.8 was released is difficult with a pure version number format without a good memory or cheat sheet. The YY.MM give us a great way to tell when a release was made and we can still have patch releases if required. Moving to a YY.MM format is better then moving to 3.0 as it still does not let me know when a release was done. If we pick say 16.03 as the LTS then every X years say 2 years (18.03 LTS) we then know which version is the LTS version. The nice part about 2 or 4 year LTS releases we know that a even number year would have a LTS release. I am open to whatever number of years people believe is the best. > >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 > Regards, Keith
