[ovs-dev] [PATCH v2] Modify release document for OVN.
Mark Michelson
mmichels at redhat.com
Fri Oct 25 21:26:05 UTC 2019
I made the suggested changes and pushed the updated document to master.
On 10/2/19 5:17 PM, Han Zhou wrote:
> 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
> <mailto: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
> <mailto: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 <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 <hzhou8 at ebay.com <mailto:hzhou8 at ebay.com>>
More information about the dev
mailing list