]>
Commit | Line | Data |
---|---|---|
f8e5a539 SF |
1 | .. |
2 | Licensed under the Apache License, Version 2.0 (the "License"); you may | |
3 | not use this file except in compliance with the License. You may obtain | |
4 | a copy of the License at | |
5 | ||
6 | http://www.apache.org/licenses/LICENSE-2.0 | |
7 | ||
8 | Unless required by applicable law or agreed to in writing, software | |
9 | distributed under the License is distributed on an "AS IS" BASIS, WITHOUT | |
10 | WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the | |
11 | License for the specific language governing permissions and limitations | |
12 | under the License. | |
13 | ||
14 | Convention for heading levels in Open vSwitch documentation: | |
15 | ||
16 | ======= Heading 0 (reserved for the title in a document) | |
17 | ------- Heading 1 | |
18 | ~~~~~~~ Heading 2 | |
19 | +++++++ Heading 3 | |
20 | ''''''' Heading 4 | |
21 | ||
22 | Avoid deeper levels because they do not render well. | |
23 | ||
24 | ============================ | |
25 | Open vSwitch Release Process | |
26 | ============================ | |
27 | ||
28 | This document describes the process ordinarily used for Open vSwitch | |
29 | development and release. Exceptions are sometimes necessary, so all of the | |
30 | statements here should be taken as subject to change through rough consensus of | |
31 | Open vSwitch contributors, obtained through public discussion on, e.g., ovs-dev | |
32 | or the #openvswitch IRC channel. | |
33 | ||
34 | Release Strategy | |
35 | ---------------- | |
36 | ||
37 | Open vSwitch feature development takes place on the "master" branch. | |
38 | Ordinarily, new features are rebased against master and applied directly. For | |
39 | features that take significant development, sometimes it is more appropriate to | |
40 | merge a separate branch into master; please discuss this on ovs-dev in advance. | |
41 | ||
c1e89198 BP |
42 | The process of making a release has the following stages. See `Release |
43 | Scheduling`_ for the timing of each stage: | |
44 | ||
45 | 1. "Soft freeze" of the master branch. | |
46 | ||
47 | During the freeze, we ask committers to refrain from applying patches that | |
48 | add new features unless those patches were already being publicly discussed | |
49 | and reviewed before the freeze began. Bug fixes are welcome at any time. | |
50 | Please propose and discuss exceptions on ovs-dev. | |
51 | ||
52 | 2. Fork a release branch from master, named for the expected release number, | |
53 | e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x. | |
54 | ||
55 | Release branches are intended for testing and stabilization. At this stage | |
56 | and in later stages, they should receive only bug fixes, not new features. | |
57 | Bug fixes applied to release branches should be backports of corresponding | |
58 | bug fixes to the master branch, except for bugs present only on release | |
59 | branches (which are rare in practice). | |
60 | ||
61 | At this stage, sometimes there can be exceptions to the rule that a release | |
62 | branch receives only bug fixes. Like bug fixes, new features on release | |
63 | branches should be backports of the corresponding commits on the master | |
64 | branch. Features to be added to release branches should be limited in scope | |
65 | and risk and discussed on ovs-dev before creating the branch. | |
66 | ||
67 | 3. When committers come to rough consensus that the release is ready, they | |
68 | release the .0 release on its branch, e.g. 2.3.0 for branch-2.3. To make | |
69 | the actual release, a committer pushes a signed tag named, e.g. v2.3.0, to | |
70 | the Open vSwitch repository, makes a release tarball available on | |
71 | openvswitch.org, and posts a release announcement to ovs-announce. | |
72 | ||
73 | 4. As bug fixes accumulate, or after important bugs or vulnerabilities are | |
74 | fixed, committers may make additional releases from a branch: 2.3.1, 2.3.2, | |
75 | and so on. The process is the same for these additional release as for a .0 | |
76 | release. | |
f8e5a539 SF |
77 | |
78 | At most two release branches are formally maintained at any given time: the | |
79 | latest release and the latest release designed as LTS. An LTS release is one | |
80 | that the OVS project has designated as being maintained for a longer period of | |
81 | time. Currently, an LTS release is maintained until the next LTS is chosen. | |
82 | There is not currently a strict guideline on how often a new LTS release is | |
83 | chosen, but so far it has been about every 2 years. That could change based on | |
84 | the current state of OVS development. For example, we do not want to designate | |
85 | a new release as LTS that includes disruptive internal changes, as that may | |
86 | make it harder to support for a longer period of time. Discussion about | |
87 | choosing the next LTS release occurs on the OVS development mailing list. | |
88 | ||
89 | Release Numbering | |
90 | ----------------- | |
91 | ||
92 | The version number on master should normally end in .90. This indicates that | |
93 | the Open vSwitch version is "almost" the next version to branch. | |
94 | ||
95 | Forking master into branch-x.y requires two commits to master. The first is | |
96 | titled "Prepare for x.y.0" and increments the version number to x.y. This is | |
97 | the initial commit on branch-x.y. The second is titled "Prepare for post-x.y.0 | |
98 | (x.y.90)" and increments the version number to x.y.90. | |
99 | ||
100 | The version number on a release branch is x.y.z, where z is initially 0. | |
101 | Making a release requires two commits. The first is titled *Set release dates | |
102 | for x.y.z.* and updates NEWS and debian/changelog to specify the release date | |
103 | of the new release. This commit is the one made into a tarball and tagged. | |
104 | The second is titled *Prepare for x.y.(z+1).* and increments the version number | |
105 | and adds a blank item to NEWS with an unspecified date. | |
106 | ||
107 | Release Scheduling | |
108 | ------------------ | |
109 | ||
c1e89198 BP |
110 | Open vSwitch makes releases at the following six-month cadence. All dates are |
111 | approximate: | |
112 | ||
113 | +---------------+----------------+--------------------------------------+ | |
114 | | Time (months) | Dates | Stage | | |
115 | +---------------+----------------+--------------------------------------+ | |
116 | | T | Mar 1, Sep 1 | Begin x.y release cycle | | |
117 | +---------------+----------------+--------------------------------------+ | |
118 | | T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y release | | |
119 | +---------------+----------------+--------------------------------------+ | |
120 | | T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master | | |
121 | +---------------+----------------+--------------------------------------+ | |
122 | | T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 | | |
123 | +---------------+----------------+--------------------------------------+ | |
f8e5a539 SF |
124 | |
125 | Contact | |
126 | ------- | |
127 | ||
128 | Use dev@openvswitch.org to discuss the Open vSwitch development and release | |
129 | process. |