Perhaps the title buried the lead. My main goal for this patch is to propose a new regular release schedule for OVS. Any comments?
Thanks, Ben. On Tue, Jul 19, 2016 at 10:58:08AM -0700, Ben Pfaff 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 <b...@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@openvswitch.org to discuss the Open vSwitch development > +and release process. > -- > 2.1.3 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
