[ovs-dev] [PATCH] release-process.md: Document OVS release process and propose a schedule.
Ben Pfaff
blp at ovn.org
Wed Jul 20 20:00:08 UTC 2016
On Wed, Jul 20, 2016 at 03:48:08PM -0400, Russell Bryant wrote:
> On Wed, Jul 20, 2016 at 12:30 PM, Ben Pfaff <blp at ovn.org> wrote:
>
> > On Wed, Jul 20, 2016 at 10:00:22AM -0400, Russell Bryant wrote:
> > > 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.
> > > I think this is a great step forward. Thank you!
> >
> > Thanks for the review.
> >
> > > 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.
> >
> > I forgot that the FAQ talked about releases. I'm appending an
> > incremental that I will fold into this patch.
> >
> > It is a good idea to describe LTS releases, but I don't have answers for
> > the questions you ask. Here are some thoughts about principles we've
> > considered before:
> >
> > * We try to avoid making releases that include disruptive internal
> > changes LTS, because they are harder to support.
> >
> > * It is good to make LTS releases at least every 2 years or so,
> > because it is useful to distributions and other downstreams, but
> > not much more often than that, because it is more work to maintain
> > multiple upstreams.
> >
> > * In the past we have maintained a given LTS until we release the
> > next LTS. This is probably too vague and may not be long enough
> > in any case.
> >
> > Anyone want to suggest what we should do?
> >
>
> I don't think needs to be very formal. It may not be all the useful to try
> to lay out a 5-year release schedule based on LTS planning, as it seems
> incredibly likely that things will change. Being specific about the
> 6-month cadence is enough commitment for me. :-)
>
> Here's some proposed text ...
>
> At most two release branches are maintained at any given time: the latest
> release and the latest release designed as LTS. An LTS release is one that
> the OVS project has designated as being maintained for a longer period of
> time. Currently, an LTS release is maintained until the next LTS is
> chosen. There is not currently a strict guideline on how often a new LTS
> release is chosen, but so far it has been about every 2 years. That could
> change based on the current state of OVS development. For example, we do
> not want to designate a new release as LTS that includes disruptive
> internal changes, as that may make it harder to support for a longer period
> of time. Discussion about choosing the next LTS release occurs on the OVS
> development mailing list.
That's good, I folded that in. Here's the current version.
--8<--------------------------cut here-------------------------->8--
From: Ben Pfaff <blp at ovn.org>
Date: Wed, 20 Jul 2016 12:59:26 -0700
Subject: [PATCH] release-process.md: Document OVS release process and propose
a schedule.
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>
Acked-by: Russell Bryant <russell at ovn.org>
---
Documentation/automake.mk | 3 +-
Documentation/release-process.md | 98 ++++++++++++++++++++++++++++++++++++++++
FAQ.md | 8 +++-
3 files changed, 106 insertions(+), 3 deletions(-)
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..9f6ef3b
--- /dev/null
+++ b/Documentation/release-process.md
@@ -0,0 +1,98 @@
+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.
+
+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 that the OVS project has designated as being
+maintained for a longer period of time. Currently, an LTS release is
+maintained until the next LTS is chosen. There is not currently a
+strict guideline on how often a new LTS release is chosen, but so far
+it has been about every 2 years. That could change based on the
+current state of OVS development. For example, we do not want to
+designate a new release as LTS that includes disruptive internal
+changes, as that may make it harder to support for a longer period of
+time. Discussion about choosing the next LTS release occurs on the
+OVS development mailing list.
+
+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.
diff --git a/FAQ.md b/FAQ.md
index 063bd70..290e66c 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -125,13 +125,16 @@ Releases
### Q: What does it mean for an Open vSwitch release to be LTS (long-term support)?
A: All official releases have been through a comprehensive testing
- process and are suitable for production use. Planned releases will
- occur several times a year. If a significant bug is identified in an
+ process and are suitable for production use. Planned releases
+ occur twice a year. If a significant bug is identified in an
LTS release, we will provide an updated release that includes the
fix. Releases that are not LTS may not be fixed and may just be
supplanted by the next major release. The current LTS release is
2.3.x.
+ For more information on the Open vSwitch release process, please
+ see [release-process.md].
+
### Q: What Linux kernel versions does each Open vSwitch release work with?
A: The following table lists the Linux kernel versions against which the
@@ -2140,3 +2143,4 @@ http://openvswitch.org/
[OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md
[INSTALL.DPDK.md]:INSTALL.DPDK.md
[Tutorial.md]:tutorial/Tutorial.md
+[release-process.md]:Documentation/release-process.md
--
2.1.3
More information about the dev
mailing list