[ovs-dev] [PATCH] release-process.md: Document OVS release process and propose a schedule.

Russell Bryant russell at ovn.org
Wed Jul 20 14:00:22 UTC 2016


On Tue, Jul 19, 2016 at 1:58 PM, Ben Pfaff <blp at ovn.org> wrote:

> This document has two different kinds of text:
>
>    - The first sections of the document, "Release Strategy" and "Release
>      Numbering", describe what we've already been doing for most of the
>      history of Open vSwitch.  If there is anything surprising in them,
>      then it's because our process has not been transparent enough, and not
>      because we're making a change.
>
>    - The final section of the document, "Release Scheduling", is a proposal
>      for current and future releases.  We have not had a regular release
>      schedule in the past, but it seems important to have one in the
>      future, so this section requires review and feedback from everyone in
>      the community.
>
> Signed-off-by: Ben Pfaff <blp at ovn.org>
> ---
>  Documentation/automake.mk        |  3 +-
>  Documentation/release-process.md | 85
> ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 87 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/release-process.md
>
> diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> index aae41d2..d709e77 100644
> --- a/Documentation/automake.mk
> +++ b/Documentation/automake.mk
> @@ -2,4 +2,5 @@ docs += \
>         Documentation/committer-responsibilities.md \
>         Documentation/committer-grant-revocation.md \
>         Documentation/group-selection-method-property.txt \
> -       Documentation/OVSDB-replication.md
> +       Documentation/OVSDB-replication.md \
> +       Documentation/release-process.md
> diff --git a/Documentation/release-process.md b/Documentation/
> release-process.md
> new file mode 100644
> index 0000000..a6af363
> --- /dev/null
> +++ b/Documentation/release-process.md
> @@ -0,0 +1,85 @@
> +Open vSwitch Release Process
> +============================
> +
> +This document describes the process ordinarily used for Open vSwitch
> +development and release.  Exceptions are sometimes necessary, so all
> +of the statements here should be taken as subject to change through
> +rough consensus of Open vSwitch contributors.
> +
> +Release Strategy
> +----------------
> +
> +Open vSwitch 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.
> +
> +Periodically, the OVS developers fork a branch from master to become
> +an official release.  These release branches are named for expected
> +release number, e.g. "branch-2.3" for the branch that will yield Open
> +vSwitch 2.3.x.  Release branches should receive only bug fixes, not
> +new features.  Bug fixes applied to release branches should be
> +backports of corresponding bug fixes to the master branch, except for
> +bugs present only on release branches (which are rare in practice).
> +
> +Sometimes there can be exceptions to the rule that a release branch
> +receives only bug fixes.  In particular, after a release branch is
> +created, but before the first actual release from that branch, it can
> +be appropriate to add features.  Like bug fixes, new features on
> +release branches should be backports of the corresponding commits on
> +the master branch.  Features to be added to release branches should be
> +limited in scope and risk and discussed on ovs-dev before creating the
> +branch.
> +
> +After a period of testing and stabilization, and rough consensus by
> +contributors that the release is ready, the developers release the .0
> +release on its branch, e.g. 2.3.0 for branch-2.3.  To make the actual
> +release, a developer pushes a signed tag named, e.g. v2.3.0, to the
> +Open vSwitch repository, makes a release tarball available on
> +openvswitch.org, and posts a release announcement to ovs-announce.
> +
> +As a number of bug fixes accumulate, or after important bugs or
> +vulnerabilities are fixed, the OVS developers 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.
> +
> +Release Numbering
> +-----------------
> +
> +The version number on master should normally end in .90.  This
> +indicates that the Open vSwitch version is "almost" the next version
> +to branch.
> +
> +Forking master into branch-x.y requires two commits to master.  The
> +first is 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.
> +
> +Release Scheduling
> +------------------
> +
> +Open vSwitch makes releases at the following six-month cadence, which
> +of course is subject to change.
> +
> +time
> +(months)  approx 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
> +
> +Contact
> +-------
> +
> +Please use dev at openvswitch.org to discuss the Open vSwitch development
> +and release process.
>

I think this is a great step forward.  Thank you!

One topic that could be added to this document is discussion of how long
each release branch is maintained.  LTS is defined in FAQ.md, but it could
be defined in this document now.  How an LTS branch is chosen, and the
maintenance difference between LTS and non-LTS would also be good topics to
cover.

Acked-by: Russell Bryant <russell at ovn.org>

-- 
Russell Bryant



More information about the dev mailing list