From patchwork Sun Oct 30 13:29:50 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Finucane X-Patchwork-Id: 688929 X-Patchwork-Delegate: rbryant@redhat.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from archives.nicira.com (archives.nicira.com [96.126.127.54]) by ozlabs.org (Postfix) with ESMTP id 3t6JLP0F94z9t1T for ; Mon, 31 Oct 2016 00:31:40 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=that.guru header.i=@that.guru header.b=Gv5SeEQQ; dkim-atps=neutral Received: from archives.nicira.com (localhost [127.0.0.1]) by archives.nicira.com (Postfix) with ESMTP id 3DCA0102DC; Sun, 30 Oct 2016 06:31:40 -0700 (PDT) X-Original-To: dev@openvswitch.org Delivered-To: dev@openvswitch.org Received: from mx1e3.cudamail.com (mx1.cudamail.com [69.90.118.67]) by archives.nicira.com (Postfix) with ESMTPS id B559B102C4 for ; Sun, 30 Oct 2016 06:31:38 -0700 (PDT) Received: from bar5.cudamail.com (localhost [127.0.0.1]) by mx1e3.cudamail.com (Postfix) with ESMTPS id 4E1CC42037A for ; Sun, 30 Oct 2016 07:31:38 -0600 (MDT) X-ASG-Debug-ID: 1477834297-09eadd0f96242990001-byXFYA Received: from mx3-pf3.cudamail.com ([192.168.14.3]) by bar5.cudamail.com with ESMTP id QfK54Xedkw01hK7j (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Oct 2016 07:31:37 -0600 (MDT) X-Barracuda-Envelope-From: stephen@that.guru X-Barracuda-RBL-Trusted-Forwarder: 192.168.14.3 Received: from unknown (HELO butterfly.birch.relay.mailchannels.net) (23.83.209.27) by mx3-pf3.cudamail.com with ESMTPS (DHE-RSA-AES256-SHA encrypted); 30 Oct 2016 13:31:36 -0000 Received-SPF: none (mx3-pf3.cudamail.com: domain at that.guru does not designate permitted sender hosts) X-Barracuda-Apparent-Source-IP: 23.83.209.27 X-Barracuda-RBL-IP: 23.83.209.27 X-Sender-Id: mxroute|x-authuser|stephen@that.guru Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B69D1A02DB for ; Sun, 30 Oct 2016 13:31:35 +0000 (UTC) Received: from one.mxroute.com (ip-10-229-10-199.us-west-2.compute.internal [10.229.10.199]) by relay.mailchannels.net (Postfix) with ESMTPA id 1A7B4A0DB4 for ; Sun, 30 Oct 2016 13:31:35 +0000 (UTC) X-Sender-Id: mxroute|x-authuser|stephen@that.guru Received: from one.mxroute.com ([UNAVAILABLE]. [10.102.194.57]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.8); Sun, 30 Oct 2016 13:31:35 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: mxroute|x-authuser|stephen@that.guru X-MailChannels-Auth-Id: mxroute X-MC-Loop-Signature: 1477834295432:4272864808 X-MC-Ingress-Time: 1477834295432 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=that.guru; s=default; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e99jCcHnYyfkGIFrPsvEw0pG0D8LoVpVQGwamfWW+Bg=; b=Gv5SeEQQuFILPnhZyjxVPUXlhB dn9L58LoqZJLXixEcRRTPD59AfiNBbKmn7iLcel4Aqee6pLGrZlFLFslusFuO1xO7iFExiHoyuvDp HHz0Q+v8UjTOX2DtudkniACj98I8+WUyTLYmnMZq7LFkz3kxa1HRxwxzL8r/G/sw3pz8EavGHPSur zLY6IGs02WrDmsdMnQz7dnD6FPi5g2M1DgUa5r7ThvuzSOpna6y7K5FsnvlYva423yKLSDiu1rf1S w6Qqc97f5dk3u/TpBx9DKbreCuEeVf4i02hHv3SjH03rtqOGcuYLYK4SaxBhVNg8bxuoDxuDO9dJ1 CZPtmJjg==; X-CudaMail-Envelope-Sender: stephen@that.guru From: Stephen Finucane To: dev@openvswitch.org X-CudaMail-MID: CM-V3-1029004300 X-CudaMail-DTE: 103016 X-CudaMail-Originating-IP: 23.83.209.27 Date: Sun, 30 Oct 2016 13:29:50 +0000 X-ASG-Orig-Subj: [##CM-V3-1029004300##][PATCH 04/23] doc: Convert release-process to rST Message-Id: <1477834209-11414-5-git-send-email-stephen@that.guru> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1477834209-11414-1-git-send-email-stephen@that.guru> References: <1477834209-11414-1-git-send-email-stephen@that.guru> X-OutGoing-Spam-Status: No, score=-9.2 X-AuthUser: stephen@that.guru X-GBUdb-Analysis: 0, 23.83.209.27, Ugly c=0.271956 p=-0.142857 Source Normal X-MessageSniffer-Rules: 0-0-0-27223-c X-Barracuda-Connect: UNKNOWN[192.168.14.3] X-Barracuda-Start-Time: 1477834297 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA X-Barracuda-URL: https://web.cudamail.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at cudamail.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.10 X-Barracuda-Spam-Status: No, SCORE=1.10 using global scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests=BSF_SC0_MV0713, BSF_SC5_MJ1963, DKIM_SIGNED, RDNS_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.34168 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC0_MV0713 Custom rule MV0713 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 Subject: [ovs-dev] [PATCH 04/23] doc: Convert release-process to rST X-BeenThere: dev@openvswitch.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dev-bounces@openvswitch.org Sender: "dev" Signed-off-by: Stephen Finucane --- Documentation/automake.mk | 2 +- Documentation/release-process.md | 99 -------------------------------- Documentation/release-process.rst | 117 ++++++++++++++++++++++++++++++++++++++ FAQ.rst | 2 +- 4 files changed, 119 insertions(+), 101 deletions(-) delete mode 100644 Documentation/release-process.md create mode 100644 Documentation/release-process.rst diff --git a/Documentation/automake.mk b/Documentation/automake.mk index 9008ee2..d6849e8 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -3,4 +3,4 @@ docs += \ Documentation/committer-grant-revocation.rst \ Documentation/group-selection-method-property.txt \ Documentation/OVSDB-replication.md \ - Documentation/release-process.md + Documentation/release-process.rst diff --git a/Documentation/release-process.md b/Documentation/release-process.md deleted file mode 100644 index 0f8f49d..0000000 --- a/Documentation/release-process.md +++ /dev/null @@ -1,99 +0,0 @@ -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, obtained through public -discussion on, e.g., ovs-dev or the #openvswitch IRC channel. - -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 -obtained from 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) | Approximate 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. diff --git a/Documentation/release-process.rst b/Documentation/release-process.rst new file mode 100644 index 0000000..4440cea --- /dev/null +++ b/Documentation/release-process.rst @@ -0,0 +1,117 @@ +.. + Licensed under the Apache License, Version 2.0 (the "License"); you may + not use this file except in compliance with the License. You may obtain + a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, WITHOUT + WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + License for the specific language governing permissions and limitations + under the License. + + Convention for heading levels in Open vSwitch documentation: + + ======= Heading 0 (reserved for the title in a document) + ------- Heading 1 + ~~~~~~~ Heading 2 + +++++++ Heading 3 + ''''''' Heading 4 + + Avoid deeper levels because they do not render well. + +============================ +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, obtained through public discussion on, e.g., ovs-dev +or the #openvswitch IRC channel. + +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 obtained from +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) | Approximate 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 +------- + +Use dev@openvswitch.org to discuss the Open vSwitch development and release +process. diff --git a/FAQ.rst b/FAQ.rst index de7aaf7..7bf901b 100644 --- a/FAQ.rst +++ b/FAQ.rst @@ -146,7 +146,7 @@ Q: What does it mean for an Open vSwitch release to be LTS (long-term support)? LTS release is 2.3.x. For more information on the Open vSwitch release process, refer to `release - process `__. + process `__. Q: What Linux kernel versions does each Open vSwitch release work with?