Hi Mark, Thanks for updating this. Please see my comments below.
On Thu, Sep 26, 2019 at 12:25 PM Mark Michelson <[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]> > --- > 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 <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
