[ovs-dev] [PATCH v2] Modify release document for OVN.

Wed Oct 2 21:17:34 UTC 2019

Hi Mark,

Thanks for updating this. Please see my comments below.

On Thu, Sep 26, 2019 at 12:25 PM Mark Michelson <mmichels at redhat.com> wrote:
>
> This is an RFC to discuss the modified release cycle of OVN compared to
> OVS. The document is mostly unchanged, with two exceptions:
>
> * The release cycle for OVN is modified to be 3 months instead of 6.
> * The version numbering for OVN is modified to use the year and month of
>   the release instead of other numbers.
>
> Signed-off-by: Mark Michelson <mmichels at redhat.com>
> ---
> v1 -> v2: Rebased
> ---
>  Documentation/internals/release-process.rst | 60
++++++++++++++---------------
>  1 file changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/internals/release-process.rst
b/Documentation/internals/release-process.rst
> index 3396177b8..8af962b49 100644
> --- a/Documentation/internals/release-process.rst
> +++ b/Documentation/internals/release-process.rst
> @@ -25,19 +25,19 @@
>  OVN Release Process
>  ===================
>
> -This document describes the process ordinarily used for OVN
> -development and release.  Exceptions are sometimes necessary, so all of
the
> -statements here should be taken as subject to change through rough
consensus of
> -OVN contributors, obtained through public discussion on, e.g., ovs-dev
> -or the #openvswitch IRC channel.
> +This document describes the process ordinarily used for OVN development
and
> +release.  Exceptions are sometimes necessary, so all of the statements
here
> +should be taken as subject to change through rough consensus of OVN
> +contributors, obtained through public discussion on, e.g., ovs-dev or the
> +#openvswitch IRC channel.
>
>  Release Strategy
>  ----------------
>
> -OVN feature development takes place on the "master" branch.
> -Ordinarily, new features are rebased against master and applied
directly.  For
> -features that take significant development, sometimes it is more
appropriate to
> -merge a separate branch into master; please discuss this on ovs-dev in
advance.
> +OVN feature development takes place on the "master" branch. Ordinarily,
new
> +features are rebased against master and applied directly.  For features
that
> +take significant development, sometimes it is more appropriate to merge a
> +separate branch into master; please discuss this on ovs-dev in advance.
>
>  The process of making a release has the following stages.  See `Release
>  Scheduling`_ for the timing of each stage:
> @@ -50,7 +50,7 @@ Scheduling`_ for the timing of each stage:
>     Please propose and discuss exceptions on ovs-dev.
>
>  2. Fork a release branch from master, named for the expected release
number,
> -   e.g. "branch-2.3" for the branch that will yield OVN 2.3.x.
> +   e.g. "branch-2019.10" for the branch that will yield OVN 2019.10.x.
>
>     Release branches are intended for testing and stabilization.  At this
stage
>     and in later stages, they should receive only bug fixes, not new
features.
> @@ -65,15 +65,15 @@ Scheduling`_ for the timing of each stage:
>     and risk and discussed on ovs-dev before creating the branch.
>
>  3. When committers come to rough consensus that the release is ready,
they
> -   release the .0 release on its branch, e.g. 2.3.0 for branch-2.3.  To
make
> -   the actual release, a committer pushes a signed tag named, e.g.
v2.3.0, to
> -   the OVN repository, makes a release tarball available on
> +   release the .0 release on its branch, e.g. 2019.10.0 for
branch-2019.10.  To
> +   make the actual release, a committer pushes a signed tag named, e.g.
> +   v2019.10.0, to the OVN repository, makes a release tarball available
on
>     openvswitch.org, and posts a release announcement to ovs-announce.
>
>  4. As bug fixes accumulate, or after important bugs or vulnerabilities
are
> -   fixed, committers may make additional releases from a branch: 2.3.1,
2.3.2,
> -   and so on.  The process is the same for these additional release as
for a .0
> -   release.
> +   fixed, committers may make additional releases from a branch:
2019.10.1,
> +   2019.10.2, and so on.  The process is the same for these additional
release
> +   as for a .0 release.
>
>  At most two release branches are formally maintained at any given time:
the
>  latest release and the latest release designed as LTS.  An LTS release
is one
> @@ -97,33 +97,33 @@ titled "Prepare for x.y.0" and increments the version
number to x.y.  This is
>  the initial commit on branch-x.y.  The second is titled "Prepare for
post-x.y.0
>  (x.y.90)" and increments the version number to x.y.90.
>
> -The version number on a release branch is x.y.z, where z is initially 0.
> -Making a release requires two commits.  The first is titled *Set release
dates
> -for x.y.z.* and updates NEWS and debian/changelog to specify the release
date
> -of the new release.  This commit is the one made into a tarball and
tagged.
> -The second is titled *Prepare for x.y.(z+1).* and increments the version
number
> -and adds a blank item to NEWS with an unspecified date.
> +The version number on a release branch is x.y.z, where x is the current
year, y
> +is the month of the release, and z is initially 0. Making a release
requires two
> +commits.  The first is titled *Set release dates for x.y.z.* and updates
NEWS
> +and debian/changelog to specify the release date of the new release.
This
> +commit is the one made into a tarball and tagged. The second is titled
*Prepare
> +for x.y.(z+1).* and increments the version number and adds a blank item
to NEWS
> +with an unspecified date.
>
>  Release Scheduling
>  ------------------
>
> -OVN makes releases at the following six-month cadence.  All dates are
> +OVN makes releases at the following three-month cadence.  All dates are
>  approximate:
>
>  +---------------+----------------+--------------------------------------+
> -| Time (months) | Dates          | Stage                                |
> +| Time (months) | Date           | Stage                                |

Shouldn't it still be "Dates" instead of "Date"?

>  +---------------+----------------+--------------------------------------+
> -| T             | Mar 1, Sep 1   | Begin x.y release cycle              |
> +| T             | Jan 1, Apr 1   | Begin x.y release cycle              |

Should it be "Jan 1, Apr 1, July 1, Oct 1"? Same for the following rows.

>  +---------------+----------------+--------------------------------------+
> -| T + 4         | Jul 1, Jan 1   | "Soft freeze" master for x.y release |
> +| T + 2         | Feb 1, May 1   | "Soft freeze" master for x.y release |

Should it be T + 1, since T means month?

>  +---------------+----------------+--------------------------------------+
> -| T + 4.5       | Jul 15, Jan 15 | Fork branch-x.y from master          |
> +| T + 2.5       | Feb 8, May 8   | Fork branch-x.y from master          |

T + 1.25

>  +---------------+----------------+--------------------------------------+
> -| T + 5.5       | Aug 15, Feb 15 | Release version x.y.0                |
> +| T + 2.75      | Feb 22, May 22 | Release version x.y.0                |
>  +---------------+----------------+--------------------------------------+
>

T + 1.75

So we are not only shortening the release cycle but also shortening the
time required for branching and releasing. I am ok with that.

Acked-by: Han Zhou <hzhou8 at ebay.com>