[dpdk-dev] releases scheduling

[Dave Neary]

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