Hi Mark,
Thanks for updating this. Please see my comments below.
On Thu, Sep 26, 2019 at 12:25 PM Mark Michelson <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
> ---
> 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 <http://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 <[email protected] <mailto:[email protected]>>
