releases scheduling

releases scheduling

[Thomas Monjalon]

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.

Re: releases scheduling

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Sunday, December 13, 2015 7:23 PM
> To: dev@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

Re: releases scheduling

[Arnon Warshavsky]

+1 for Ubuntu version numbering

On Tue, Dec 15, 2015 at 3:37 PM, O'Driscoll, Tim <tim.odriscoll@intel.com>
wrote:

>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Sunday, December 13, 2015 7:23 PM
> > To: dev@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
>



-- 

*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com
<arnon@qwilt.com>*

Re: releases scheduling

[Wiles, Keith]

On 12/15/15, 7:37 AM, "dev on behalf of O'Driscoll, Tim" <dev-bounces@dpdk.org on behalf of tim.odriscoll@intel.com> wrote:

>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Sunday, December 13, 2015 7:23 PM
>> To: dev@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.

+1 for the Ubuntu number and the LTS
>
>
>Tim
>


Regards,
Keith

Re: releases scheduling

[Jay Rolette]

+100 for the LTS

One of the bigger challenges for products using DPDK is that there is so
much change going in each release with very limited testing. Trying to even
remotely keep up is too risky. We end up back-porting various fixes and
enhancements to whatever version we are on (1.6rc2 currently).

Jay

On Tue, Dec 15, 2015 at 8:42 AM, Wiles, Keith <keith.wiles@intel.com> wrote:

> On 12/15/15, 7:37 AM, "dev on behalf of O'Driscoll, Tim" <
> dev-bounces@dpdk.org on behalf of tim.odriscoll@intel.com> wrote:
>
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> >> Sent: Sunday, December 13, 2015 7:23 PM
> >> To: dev@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.
>
> +1 for the Ubuntu number and the LTS
> >
> >
> >Tim
> >
>
>
> Regards,
> Keith
>
>
>
>
>

Re: 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@dpdk.org] On Behalf Of Thomas Monjalon
>> Sent: Sunday, December 13, 2015 7:23 PM
>> To: dev@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

Re: releases scheduling

[Wiles, Keith]

On 12/15/15, 1:15 PM, "dev on behalf of Dave Neary" <dev-bounces@dpdk.org on behalf of dneary@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@dpdk.org] On Behalf Of Thomas Monjalon
>>> Sent: Sunday, December 13, 2015 7:23 PM
>>> To: dev@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

Re: releases scheduling

[Vincent JARDIN]

On 15/12/2015 22:15, Wiles, Keith wrote:
> I see the YY.MM.PP (PP is patch number) as the simplest way to keep track of when a release was done.

+1

I like it.

Re: releases scheduling

[Thomas Monjalon]

2015-12-13 20:22, Thomas Monjalon:
> 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.

It seems everybody agree with this new scheduling.
The web site will be updated accordingly:
http://dpdk.org/ml/archives/web/2015-December/000008.html

There were some discussions to change the numbering scheme
and rename 2.3 to 16.04. The patch (with arguments) is welcome.
I won't do the patch myself because I don't care :)

Another discussion was about having a long term support,
i.e. doing some backport maintenance during a given period for
some selected releases.

Re: releases scheduling

[Wiles, Keith]

On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" <dev-bounces@dpdk.org on behalf of thomas.monjalon@6wind.com> wrote:

>2015-12-13 20:22, Thomas Monjalon:
>> 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.
>
>It seems everybody agree with this new scheduling.
>The web site will be updated accordingly:
>http://dpdk.org/ml/archives/web/2015-December/000008.html
>
>There were some discussions to change the numbering scheme
>and rename 2.3 to 16.04. The patch (with arguments) is welcome.
>I won't do the patch myself because I don't care :)
>
>Another discussion was about having a long term support,
>i.e. doing some backport maintenance during a given period for
>some selected releases.

I think we need to decide on the YY.MM.PP format then select
the dates for release now. This way we have it out of the way.

The date of the release is the first day of the month for the release.

March 1st - 15th is 16.03    Patches for 16.03 are from now to Feb 15th
    Try to get the release out as close to the 1st as possible.
    This one is a short release.
June  1st - 15th is 16.06    For 16.06 March 1st to May 15th
Sept  1st - 15th is 16.09    For 16.09 June 1st to Aug 15th
Dec   1st - 15th is 16.12    For 16.12 Sept 1st to Nov 15th.

The 15th just before the release month is the deadline for patches, gives up 2 weeks before the release date and to the 15th of the release month to get the release out, but we should try for the 1st. The deadline is just a suggestion here or example, we can adjust it to something else.

Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it as LTS Long Term Support as well.


Here are highlights from the other thread around the patch of version numbers.
http://dpdk.org/ml/archives/dev/2015-December/030560.html 

>
>>> >>
>>> >> What about the discussion about the numbering of DPDK versions in
>>> future? The
>>> >> latest suggest which was +1'ed a number of times was to use an
>>> Ubuntu-style
>>> >> YY.MM naming scheme. I don't think there was any objections to such a
>>> scheme
>>> >> so is it not premature to start naming the new release now using the
>>> old scheme?
>>> >
>>> >Before doing any change on master, it is better to change the version
>>> number
>>> >to avoid confusion with the previous release. Example, the generated
>>> doc does
>>> >not show 2.2 anymore.
>>> >
>>> >About changing the numbering, no problem, it can be changed at any time
>>> before
>>> >the RC1. At the moment there was a proposal for YY.MM and a proposal
>>> for 3.0.
>>> >Even the YY.MM needs more discussion as it is not clear if we should
>>> use 15.03
>>> >or 15.04 for the release ending at the end of March. It seems
>>> reasonnable to
>>> >expect a release the next day, i.e. in April.
>>> 
>>> I believe the numbering should be 16.03, 16.06, 16.09 and 16.12. As for
>>> 2.2.0 we should give it a second name 15.12 == 2.2.0 (and add a label in
>>> Git), then we can start with 16.03 as the next release number. All
>>> efforts should be made to meet the months 3, 6, 9 and 12, if one happens
>>> to be into the next month for some reason then we still label and call
>>> it the correct release number.
>>
>>When you say "the correct release number" I think you mean that if a release is planned for March but is actually completed in April, it would still be called 16.03. I believe Ubuntu take the opposite approach, and if a release does slip it gets the number for the month it's actually completed in (16.04 in this example). There are advantages and disadvantages to both approaches. We'll need to decide which approach is best.
>I just figured keeping the number the release number as expected was the best. I do not remember Ubuntu release numbers not on 4 or 10, but I could wrong. Most likely moving the release date to the first of the month is the right solution anyway. The only problem with 16.04 or April 1st is April fools day, but it really is not a big problem as long as we do not call it April 1st only YY.04.
>>
>>The best way to avoid confusion it to move from planning releases for the end of a month to planning them for the start of a month. So, as Thomas suggested above, we shouldn't plan our next release for the end of March, but for the start of April instead. That way it becomes 16.04, and we have a month of leeway in case there is a slip.

>I guess the release numbers would be 16.04, 16.07, 16.10 and then 17.01, 17.04, 17.07, 17.10 which is fine. I just liked the 3, 6, 9, 12 number scheme multiple of 3. If we stick with 3,6,9,12 and 16.03 release date would be 2016.03.01 for the first of the month. The next release after 15.12 will be a short release cycle and we get to keep the multiple of 3. :-)
>Plus with the end of year stuff it would be best to start a release on Dec 1st then on Jan 1st, right?





Regards,
Keith

Re: releases scheduling

[Thomas Monjalon]

2015-12-19 02:16, Wiles, Keith:
> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" <dev-bounces@dpdk.org on behalf of thomas.monjalon@6wind.com> wrote:
> 
> >2015-12-13 20:22, Thomas Monjalon:
> >> 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.
> >
> >It seems everybody agree with this new scheduling.
> >The web site will be updated accordingly:
> >http://dpdk.org/ml/archives/web/2015-December/000008.html
> >
> >There were some discussions to change the numbering scheme
> >and rename 2.3 to 16.04. The patch (with arguments) is welcome.
> >I won't do the patch myself because I don't care :)
> >
> >Another discussion was about having a long term support,
> >i.e. doing some backport maintenance during a given period for
> >some selected releases.
> 
> I think we need to decide on the YY.MM.PP format then select
> the dates for release now. This way we have it out of the way.
> 
> The date of the release is the first day of the month for the release.
> 
> March 1st - 15th is 16.03    Patches for 16.03 are from now to Feb 15th
>     Try to get the release out as close to the 1st as possible.
>     This one is a short release.
> June  1st - 15th is 16.06    For 16.06 March 1st to May 15th
> Sept  1st - 15th is 16.09    For 16.09 June 1st to Aug 15th
> Dec   1st - 15th is 16.12    For 16.12 Sept 1st to Nov 15th.
> 
> The 15th just before the release month is the deadline for patches, gives up 2 weeks before the release date and to the 15th of the release month to get the release out, but we should try for the 1st. The deadline is just a suggestion here or example, we can adjust it to something else.
> 
> Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it as LTS Long Term Support as well.

Hi Keith,
I'm confused. Have you read the proposal above and the patch above?
I add it here again to make it more visible:
	http://dpdk.org/ml/archives/web/2015-December/000008.html
And I copy-paste here:
	The release cycles are progressively shorten during 2016.
	Release 16.04
		Proposal deadline: January 31
		Integration deadline: March 10
		Release: April 7
	Release 16.07 
		Proposal deadline: May 8
		Integration deadline: June 16
		Release: July 18
	Release 16.11
		Proposal deadline: August 28
		Integration deadline: September 30
		Release: November 2
	Release 17.02
		Release: February 1
	Release 17.05
		Release: May 2
	Release 17.08
		Release: August 1
	Release 17.11
		Release: November 2

Re: releases scheduling

[Wiles, Keith]

On 12/19/15, 3:47 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:

>2015-12-19 02:16, Wiles, Keith:
>> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" <dev-bounces@dpdk.org on behalf of thomas.monjalon@6wind.com> wrote:
>> 
>> >2015-12-13 20:22, Thomas Monjalon:
>> >> 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.
>> >
>> >It seems everybody agree with this new scheduling.
>> >The web site will be updated accordingly:
>> >http://dpdk.org/ml/archives/web/2015-December/000008.html
>> >
>> >There were some discussions to change the numbering scheme
>> >and rename 2.3 to 16.04. The patch (with arguments) is welcome.
>> >I won't do the patch myself because I don't care :)
>> >
>> >Another discussion was about having a long term support,
>> >i.e. doing some backport maintenance during a given period for
>> >some selected releases.
>> 
>> I think we need to decide on the YY.MM.PP format then select
>> the dates for release now. This way we have it out of the way.
>> 
>> The date of the release is the first day of the month for the release.
>> 
>> March 1st - 15th is 16.03    Patches for 16.03 are from now to Feb 15th
>>     Try to get the release out as close to the 1st as possible.
>>     This one is a short release.
>> June  1st - 15th is 16.06    For 16.06 March 1st to May 15th
>> Sept  1st - 15th is 16.09    For 16.09 June 1st to Aug 15th
>> Dec   1st - 15th is 16.12    For 16.12 Sept 1st to Nov 15th.
>> 
>> The 15th just before the release month is the deadline for patches, gives up 2 weeks before the release date and to the 15th of the release month to get the release out, but we should try for the 1st. The deadline is just a suggestion here or example, we can adjust it to something else.
>> 
>> Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it as LTS Long Term Support as well.
>
>Hi Keith,
>I'm confused. Have you read the proposal above and the patch above?
>I add it here again to make it more visible:
>	http://dpdk.org/ml/archives/web/2015-December/000008.html
>And I copy-paste here:
>	The release cycles are progressively shorten during 2016.
>	Release 16.04
>		Proposal deadline: January 31
>		Integration deadline: March 10
>		Release: April 7
>	Release 16.07 
>		Proposal deadline: May 8
>		Integration deadline: June 16
>		Release: July 18
>	Release 16.11
>		Proposal deadline: August 28
>		Integration deadline: September 30
>		Release: November 2
>	Release 17.02
>		Release: February 1
>	Release 17.05
>		Release: May 2
>	Release 17.08
>		Release: August 1
>	Release 17.11
>		Release: November 2

Hi Thomas,

The reason I keep stating my dates above is to make the release month the same each year not move them around each year. If we move the release months around it will be difficult to determine when the next release is to be done. I think we are both trying to increase the number of releases per year to reduce the work per release. I am trying to get a fixed release month each year just like Ubuntu has 04 and 10 each year.

Please consider making the months fixed instead of having them move a bit each year.

I will shut up about the dates now and let you/others decide, I do not want to upset anyone.
I hope I have been a bit clearer as to what I was trying to accomplish with my comments. 
>


Regards,
Keith

Re: releases scheduling

[Thomas Monjalon]

2015-12-19 16:21, Wiles, Keith:
> On 12/19/15, 3:47 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
> >2015-12-19 02:16, Wiles, Keith:
> >> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" wrote:
> >> >2015-12-13 20:22, Thomas Monjalon:
> >> >> 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.
> >> >
> >> >It seems everybody agree with this new scheduling.
> >> >The web site will be updated accordingly:
> >> >http://dpdk.org/ml/archives/web/2015-December/000008.html
> >> >
> >> >There were some discussions to change the numbering scheme
> >> >and rename 2.3 to 16.04. The patch (with arguments) is welcome.
> >> >I won't do the patch myself because I don't care :)
> >> >
> >> >Another discussion was about having a long term support,
> >> >i.e. doing some backport maintenance during a given period for
> >> >some selected releases.
> >> 
> >> I think we need to decide on the YY.MM.PP format then select
> >> the dates for release now. This way we have it out of the way.
> >> 
> >> The date of the release is the first day of the month for the release.
> >> 
> >> March 1st - 15th is 16.03    Patches for 16.03 are from now to Feb 15th
> >>     Try to get the release out as close to the 1st as possible.
> >>     This one is a short release.
> >> June  1st - 15th is 16.06    For 16.06 March 1st to May 15th
> >> Sept  1st - 15th is 16.09    For 16.09 June 1st to Aug 15th
> >> Dec   1st - 15th is 16.12    For 16.12 Sept 1st to Nov 15th.
> >> 
> >> The 15th just before the release month is the deadline for patches, gives up 2 weeks before the release date and to the 15th of the release month to get the release out, but we should try for the 1st. The deadline is just a suggestion here or example, we can adjust it to something else.
> >> 
> >> Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it as LTS Long Term Support as well.
> >
> >Hi Keith,
> >I'm confused. Have you read the proposal above and the patch above?
> >I add it here again to make it more visible:
> >	http://dpdk.org/ml/archives/web/2015-December/000008.html
> >And I copy-paste here:
> >	The release cycles are progressively shorten during 2016.
> >	Release 16.04
> >		Proposal deadline: January 31
> >		Integration deadline: March 10
> >		Release: April 7
> >	Release 16.07 
> >		Proposal deadline: May 8
> >		Integration deadline: June 16
> >		Release: July 18
> >	Release 16.11
> >		Proposal deadline: August 28
> >		Integration deadline: September 30
> >		Release: November 2
> >	Release 17.02
> >		Release: February 1
> >	Release 17.05
> >		Release: May 2
> >	Release 17.08
> >		Release: August 1
> >	Release 17.11
> >		Release: November 2
> 
> Hi Thomas,
> 
> The reason I keep stating my dates above is to make the release month the same each year not move them around each year. If we move the release months around it will be difficult to determine when the next release is to be done. I think we are both trying to increase the number of releases per year to reduce the work per release. I am trying to get a fixed release month each year just like Ubuntu has 04 and 10 each year.
> 
> Please consider making the months fixed instead of having them move a bit each year.

Yes that's what I considered. The dates are not the same in 2016 and 2017
because of the progressive change.
But 2017 and 2018 should be identical.
And more importantly, these dates should respect the major holidays.

> I will shut up about the dates now and let you/others decide, I do not want to upset anyone.
> I hope I have been a bit clearer as to what I was trying to accomplish with my comments. 

Yes thank you Keith, it's a lot clearer.
When your comments are argumented, it's a pleasure to discuss :)

Re: releases scheduling

[O'Driscoll, Tim]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Saturday, December 19, 2015 8:14 PM
> To: Wiles, Keith
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] releases scheduling
> 
> 2015-12-19 16:21, Wiles, Keith:
> > On 12/19/15, 3:47 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com>
> wrote:
> > >2015-12-19 02:16, Wiles, Keith:
> > >> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" wrote:
> > >> >2015-12-13 20:22, Thomas Monjalon:
> > >> >> 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.
> > >> >
> > >> >It seems everybody agree with this new scheduling.
> > >> >The web site will be updated accordingly:
> > >> >http://dpdk.org/ml/archives/web/2015-December/000008.html
> > >> >
> > >> >There were some discussions to change the numbering scheme
> > >> >and rename 2.3 to 16.04. The patch (with arguments) is welcome.
> > >> >I won't do the patch myself because I don't care :)
> > >> >
> > >> >Another discussion was about having a long term support,
> > >> >i.e. doing some backport maintenance during a given period for
> > >> >some selected releases.
> > >>
> > >> I think we need to decide on the YY.MM.PP format then select
> > >> the dates for release now. This way we have it out of the way.
> > >>
> > >> The date of the release is the first day of the month for the
> release.
> > >>
> > >> March 1st - 15th is 16.03    Patches for 16.03 are from now to Feb
> 15th
> > >>     Try to get the release out as close to the 1st as possible.
> > >>     This one is a short release.
> > >> June  1st - 15th is 16.06    For 16.06 March 1st to May 15th
> > >> Sept  1st - 15th is 16.09    For 16.09 June 1st to Aug 15th
> > >> Dec   1st - 15th is 16.12    For 16.12 Sept 1st to Nov 15th.
> > >>
> > >> The 15th just before the release month is the deadline for patches,
> gives up 2 weeks before the release date and to the 15th of the release
> month to get the release out, but we should try for the 1st. The
> deadline is just a suggestion here or example, we can adjust it to
> something else.
> > >>
> > >> Tag 2.2.0 in the repo also as 15.12 plus I would suggest we tag it
> as LTS Long Term Support as well.
> > >
> > >Hi Keith,
> > >I'm confused. Have you read the proposal above and the patch above?
> > >I add it here again to make it more visible:
> > >	http://dpdk.org/ml/archives/web/2015-December/000008.html
> > >And I copy-paste here:
> > >	The release cycles are progressively shorten during 2016.
> > >	Release 16.04
> > >		Proposal deadline: January 31
> > >		Integration deadline: March 10
> > >		Release: April 7
> > >	Release 16.07
> > >		Proposal deadline: May 8
> > >		Integration deadline: June 16
> > >		Release: July 18
> > >	Release 16.11
> > >		Proposal deadline: August 28
> > >		Integration deadline: September 30
> > >		Release: November 2
> > >	Release 17.02
> > >		Release: February 1
> > >	Release 17.05
> > >		Release: May 2
> > >	Release 17.08
> > >		Release: August 1
> > >	Release 17.11
> > >		Release: November 2
> >
> > Hi Thomas,
> >
> > The reason I keep stating my dates above is to make the release month
> the same each year not move them around each year. If we move the
> release months around it will be difficult to determine when the next
> release is to be done. I think we are both trying to increase the number
> of releases per year to reduce the work per release. I am trying to get
> a fixed release month each year just like Ubuntu has 04 and 10 each
> year.
> >
> > Please consider making the months fixed instead of having them move a
> bit each year.
> 
> Yes that's what I considered. The dates are not the same in 2016 and
> 2017
> because of the progressive change.
> But 2017 and 2018 should be identical.
> And more importantly, these dates should respect the major holidays.

+1

I think this is a good compromise. It changes the release dates for 2016 gradually, so it avoids disrupting any existing plans. It also avoids the major holiday periods as much as possible, and gives us a consistent release schedule from 2017 onwards.

> 
> > I will shut up about the dates now and let you/others decide, I do not
> want to upset anyone.
> > I hope I have been a bit clearer as to what I was trying to accomplish
> with my comments.
> 
> Yes thank you Keith, it's a lot clearer.
> When your comments are argumented, it's a pleasure to discuss :)

Re: releases scheduling

[Thomas Monjalon]

2015-12-19 22:58, O'Driscoll, Tim:
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > 2015-12-19 16:21, Wiles, Keith:
> > > On 12/19/15, 3:47 AM, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:
> > > >2015-12-19 02:16, Wiles, Keith:
> > > >> On 12/18/15, 6:01 PM, "dev on behalf of Thomas Monjalon" wrote:
> > > >> >2015-12-13 20:22, Thomas Monjalon:
> > > >> >> 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.
> > > >> >
> > > >> >It seems everybody agree with this new scheduling.
> > > >> >The web site will be updated accordingly:
> > > >> >http://dpdk.org/ml/archives/web/2015-December/000008.html
[...]
> > > >I add it here again to make it more visible:
> > > >	http://dpdk.org/ml/archives/web/2015-December/000008.html
> > > >And I copy-paste here:
> > > >	The release cycles are progressively shorten during 2016.
> > > >	Release 16.04
> > > >		Proposal deadline: January 31
> > > >		Integration deadline: March 10
> > > >		Release: April 7
> > > >	Release 16.07
> > > >		Proposal deadline: May 8
> > > >		Integration deadline: June 16
> > > >		Release: July 18
> > > >	Release 16.11
> > > >		Proposal deadline: August 28
> > > >		Integration deadline: September 30
> > > >		Release: November 2
> > > >	Release 17.02
> > > >		Release: February 1
> > > >	Release 17.05
> > > >		Release: May 2
> > > >	Release 17.08
> > > >		Release: August 1
> > > >	Release 17.11
> > > >		Release: November 2
[...]
> > > Please consider making the months fixed instead of having them move a
> > bit each year.
> > 
> > Yes that's what I considered. The dates are not the same in 2016 and
> > 2017
> > because of the progressive change.
> > But 2017 and 2018 should be identical.
> > And more importantly, these dates should respect the major holidays.
> 
> +1
> 
> I think this is a good compromise. It changes the release dates for 2016 gradually, so it avoids disrupting any existing plans. It also avoids the major holiday periods as much as possible, and gives us a consistent release schedule from 2017 onwards.

So it will be applied and visble on the web site.
Thanks for your comments

releases scheduling

[Thomas Monjalon]

Hi everybody,

The deadlines for the next releases are available on the website:
	http://dpdk.org/dev/roadmap#dates

Release 16.07
    Proposal deadline: May 8
    Integration deadline: June 16
    Release: July 18
Release 16.11
    Proposal deadline: August 28
    Integration deadline: September 30
    Release: November 2
Release 17.02
    Release: February 1
Release 17.05
    Release: May 2
Release 17.08
    Release: August 1
Release 17.11
    Release: November 2

The planning try to preserve some of the major holiday periods
(February, May, August, December).

Let's put more details for the next year:

Release 17.02
    Proposal deadline: December 4
    Integration deadline: January 5
    Release: February 1
Release 17.05
    Proposal deadline: February 26
    Integration deadline: March 30
    Release: May 2
Release 17.08
    Proposal deadline: May 28
    Integration deadline: June 29
    Release: August 1

As usual, comments are welcome