[dpdk-dev] releases scheduling

Wiles, Keith keith.wiles at intel.com
Tue Dec 15 22:15:04 CET 2015


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






More information about the dev mailing list