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

Russell Bryant russell at ovn.org
Mon Oct 31 19:22:44 UTC 2016


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

>
> > On Oct 29, 2016, at 9:19 AM, Russell Bryant <russell at 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.

-- 
Russell Bryant



More information about the dev mailing list