[ovs-dev] release: Propose a shorter release cycle for 2.7.

OVS recently adopted a six month release cycle.  OVS doesn't
have to align to other projects, but it can be beneficial.
The dates for OVS 2.6 aligned very well to OpenStack,
which is a major consumer of OVS that usually does 6 month releases.

OpenStack is doing a short release cycle for its Ocata release
to adjust to changes to their event schedule.  Propose earlier
dates for OVS 2.7 that keep OVS releasing just ahead of OpenStack.

This patch also proposes creating the release branch 4 weeks ahead of
the release instead of 6 to help lessen the impact of the shorter
release cycle.

https://releases.openstack.org/ocata/schedule.html

Signed-off-by: Russell Bryant <russell@ovn.org>
---
 Documentation/release-process.md | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

> On Oct 29, 2016, at 9:19 AM, Russell Bryant <russell@ovn.org> wrote:
> 
> diff --git a/Documentation/release-process.md b/Documentation/release-process.md
> index 0f8f49d..0c53812 100644
> --- a/Documentation/release-process.md
> +++ b/Documentation/release-process.md
> @@ -83,14 +83,24 @@ NEWS with an unspecified date.
> Release Scheduling
> ------------------
> 
> -Open vSwitch makes releases at the following six-month cadence, which
> -of course is subject to change.
> -
> -| Time (months) | Approximate Dates | Event                                |
> -|---------------|-------------------|--------------------------------------|
> -| T             | Apr 1, Oct 1      | Release cycle for version x.y begins |
> -| T + 4         | Aug 1, Feb 1      | branch-x.y forks from master         |
> -| T + 5.5       | Sep 15, Mar 15    | branch-x.y released as version x.y.0 |
> +Open vSwitch makes releases at approximately a six-month cadence.
> +Specific dates are chosen as a target for each release and may vary
> +from exactly six months if deemed appropriate, such as to help
> +align with other projects related to Open vSwitch.
> +
> +In addition to a target release date, each release cycle also has a branch
> +creation target date.  Once a release branch has been created, the bar is
> +raised on what can be merged for that release.  Prior to the release,
> +additional features may be merged, but generally only things that were
> +already in progress and targeted at that release.

Some of this is covered in the "Release Strategy" section.  This makes it a bit more explicit, but I think it may be better just to improve the existing text rather than repeat it.

> +
> +The following table identifies the planned dates for upcoming release
> +milestones.
> +
> +| Release Milestone              | Approximate Date  |
> +| ------------------------------ | ----------------- |
> +| branch-2.7 created             | Jan 11, 2017      |
> +| 2.7.0 released from branch-2.7 | Feb 8, 2017       |

I'm fine with jiggering our release schedule for 2.7.  However, this changes from a formula-based table to one specific to 2.7.  Is there a reason you didn't just adjust the dates in the original table?  I'm hoping that we won't be shifting the dates all that often that we'd need to update the documentation for each release.

--Justin

On Mon, Oct 31, 2016 at 5:23 PM, Justin Pettit <jpettit@ovn.org> wrote:

>
> > On Oct 29, 2016, at 9:19 AM, Russell Bryant <russell@ovn.org> wrote:
> >
> > diff --git a/Documentation/release-process.md b/Documentation/release-
> process.md
> > index 0f8f49d..0c53812 100644
> > --- a/Documentation/release-process.md
> > +++ b/Documentation/release-process.md
> > @@ -83,14 +83,24 @@ NEWS with an unspecified date.
> > Release Scheduling
> > ------------------
> >
> > -Open vSwitch makes releases at the following six-month cadence, which
> > -of course is subject to change.
> > -
> > -| Time (months) | Approximate Dates | Event
>     |
> > -|---------------|-------------------|----------------------
> ----------------|
> > -| T             | Apr 1, Oct 1      | Release cycle for version x.y
> begins |
> > -| T + 4         | Aug 1, Feb 1      | branch-x.y forks from master
>    |
> > -| T + 5.5       | Sep 15, Mar 15    | branch-x.y released as version
> x.y.0 |
> > +Open vSwitch makes releases at approximately a six-month cadence.
> > +Specific dates are chosen as a target for each release and may vary
> > +from exactly six months if deemed appropriate, such as to help
> > +align with other projects related to Open vSwitch.
> > +
> > +In addition to a target release date, each release cycle also has a
> branch
> > +creation target date.  Once a release branch has been created, the bar
> is
> > +raised on what can be merged for that release.  Prior to the release,
> > +additional features may be merged, but generally only things that were
> > +already in progress and targeted at that release.
>
> Some of this is covered in the "Release Strategy" section.  This makes it
> a bit more explicit, but I think it may be better just to improve the
> existing text rather than repeat it.
>

Sounds good.  I'll go back and read that section and see what changes to
apply.


>
> > +
> > +The following table identifies the planned dates for upcoming release
> > +milestones.
> > +
> > +| Release Milestone              | Approximate Date  |
> > +| ------------------------------ | ----------------- |
> > +| branch-2.7 created             | Jan 11, 2017      |
> > +| 2.7.0 released from branch-2.7 | Feb 8, 2017       |
>
> I'm fine with jiggering our release schedule for 2.7.  However, this
> changes from a formula-based table to one specific to 2.7.  Is there a
> reason you didn't just adjust the dates in the original table?  I'm hoping
> that we won't be shifting the dates all that often that we'd need to update
> the documentation for each release.


I was thinking we'd update this for every release.  We'd be aiming for six
months, but we'd pick specific dates each time, after looking at alignment
or conflicts (major holidays, events, other project schedules, ...).
Another reason was that I was proposing a shorter time between branch-2.7
creation and release for the shorter release cycle, so it didn't fit the
formula.  I don't mind changing the table back, but then I'm not sure where
to document the proposed deviation from the formula for 2.7.

> On Oct 31, 2016, at 12:22 PM, Russell Bryant <russell@ovn.org> wrote:
> 
> 
> 
> On Mon, Oct 31, 2016 at 5:23 PM, Justin Pettit <jpettit@ovn.org> wrote:
> 
>> > On Oct 29, 2016, at 9:19 AM, Russell Bryant <russell@ovn.org> wrote:
>> >
>> > +
>> > +The following table identifies the planned dates for upcoming release
>> > +milestones.
>> > +
>> > +| Release Milestone              | Approximate Date  |
>> > +| ------------------------------ | ----------------- |
>> > +| branch-2.7 created             | Jan 11, 2017      |
>> > +| 2.7.0 released from branch-2.7 | Feb 8, 2017       |
>> 
>> I'm fine with jiggering our release schedule for 2.7.  However, this changes from a formula-based table to one specific to 2.7.  Is there a reason you didn't just adjust the dates in the original table?  I'm hoping that we won't be shifting the dates all that often that we'd need to update the documentation for each release.
>> 
> I was thinking we'd update this for every release.  We'd be aiming for six months, but we'd pick specific dates each time, after looking at alignment or conflicts (major holidays, events, other project schedules, ...).  Another reason was that I was proposing a shorter time between branch-2.7 creation and release for the shorter release cycle, so it didn't fit the formula.  I don't mind changing the table back, but then I'm not sure where to document the proposed deviation from the formula for 2.7.

I understand the logic, but I think if we update it every release, it won't give people much confidence that there's a regular release cadence--even if we do adhere to it.  There's already some wiggle-room in the dates, so I wouldn't expect holidays and other events to cause us to miss the deadlines by much.  In terms of the 2.7 release, I think the commit message does a fine job of explaining why the dates were modified.

--Justin

On Mon, Oct 31, 2016 at 10:53 PM, Justin Pettit <jpettit@ovn.org> wrote:

>
> > On Oct 31, 2016, at 12:22 PM, Russell Bryant <russell@ovn.org> wrote:
> >
> >
> >
> > On Mon, Oct 31, 2016 at 5:23 PM, Justin Pettit <jpettit@ovn.org> wrote:
> >
> >> > On Oct 29, 2016, at 9:19 AM, Russell Bryant <russell@ovn.org> wrote:
> >> >
> >> > +
> >> > +The following table identifies the planned dates for upcoming release
> >> > +milestones.
> >> > +
> >> > +| Release Milestone              | Approximate Date  |
> >> > +| ------------------------------ | ----------------- |
> >> > +| branch-2.7 created             | Jan 11, 2017      |
> >> > +| 2.7.0 released from branch-2.7 | Feb 8, 2017       |
> >>
> >> I'm fine with jiggering our release schedule for 2.7.  However, this
> changes from a formula-based table to one specific to 2.7.  Is there a
> reason you didn't just adjust the dates in the original table?  I'm hoping
> that we won't be shifting the dates all that often that we'd need to update
> the documentation for each release.
> >>
> > I was thinking we'd update this for every release.  We'd be aiming for
> six months, but we'd pick specific dates each time, after looking at
> alignment or conflicts (major holidays, events, other project schedules,
> ...).  Another reason was that I was proposing a shorter time between
> branch-2.7 creation and release for the shorter release cycle, so it didn't
> fit the formula.  I don't mind changing the table back, but then I'm not
> sure where to document the proposed deviation from the formula for 2.7.
>
> I understand the logic, but I think if we update it every release, it
> won't give people much confidence that there's a regular release
> cadence--even if we do adhere to it.  There's already some wiggle-room in
> the dates, so I wouldn't expect holidays and other events to cause us to
> miss the deadlines by much.  In terms of the 2.7 release, I think the
> commit message does a fine job of explaining why the dates were modified.
>

OK, I'll send out a v2.