[ovs-dev] [PATCH] release-process.rst: Add "soft freeze" stage.
Ian Stokes
ian.stokes at intel.com
Thu Jul 5 18:33:06 UTC 2018
On 7/2/2018 9:57 PM, Ben Pfaff wrote:
> The last few OVS releases have included a "soft freeze" stage in the
> release process, but this stage has never been formalized in the
> documentation. This adds a description.
>
> Signed-off-by: Ben Pfaff <blp at ovn.org>
> ---
> Documentation/internals/release-process.rst | 87 ++++++++++++++++-------------
> 1 file changed, 48 insertions(+), 39 deletions(-)
>
> diff --git a/Documentation/internals/release-process.rst b/Documentation/internals/release-process.rst
> index 7ecac0a5f5d3..293fb13683f7 100644
> --- a/Documentation/internals/release-process.rst
> +++ b/Documentation/internals/release-process.rst
> @@ -39,33 +39,40 @@ 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.
> +The process of making a release has the following stages. See `Release
> +Scheduling`_ for the timing of each stage:
> +
> +1. "Soft freeze" of the master branch.
> +
> + During the freeze, we ask committers to refrain from applying patches that
> + add new features unless those patches were already being publicly discussed
> + and reviewed before the freeze began. Bug fixes are welcome at any time. > +
Would there ever be an exception here? I'm thinking if a patch is
submitted for an existing feature and the patch is deemed low risk (i.e.
fairly simple but useful). I'm aware we want to draw up a deadline and
stick to it but in the case like this should an exception be requested
from a maintainer? Or do we stick to hard deadline and only previously
discussed patches allowed.
> +2. Fork a release branch from master, named for the expected release number,
> + e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x.
> +
> + Release branches are intended for testing and stabilization. At this stage
> + and in later stages, they 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).
> +
> + At this stage, sometimes there can be exceptions to the rule that a release
> + branch receives only bug fixes. 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.
> +
> +3. When committers come to rough consensus that the release is ready, they
> + release the .0 release on its branch, e.g. 2.3.0 for branch-2.3. To make
> + the actual release, a committer 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.
> +
> +4. As bug fixes accumulate, or after important bugs or vulnerabilities are
> + fixed, committers 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
> @@ -99,18 +106,20 @@ 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 | Mar 1, Sep 1 | Release cycle for version x.y begins |
> -+-------------------+-----------------------+--------------------------------------+
> -| T + 4 | Jul 1, Jan 1 | branch-x.y forks from master |
> -+-------------------+-----------------------+--------------------------------------+
> -| T + 5.5 | Aug 15, Feb 15 | branch-x.y released as version x.y.0 |
> -+-------------------+-----------------------+--------------------------------------+
> +Open vSwitch makes releases at the following six-month cadence. All dates are
> +approximate:
> +
> ++---------------+----------------+--------------------------------------+
> +| Time (months) | Dates | Stage |
> ++---------------+----------------+--------------------------------------+
> +| T | Mar 1, Sep 1 | Begin x.y release cycle |
> ++---------------+----------------+--------------------------------------+
> +| T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y release |
> ++---------------+----------------+--------------------------------------+
> +| T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master |
> ++---------------+----------------+--------------------------------------+
> +| T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 |
> ++---------------+----------------+--------------------------------------+
>
Other than my query above this looks good, I like the 4 week
stabilization period for beg fixes before release. Should be helpful.
Ian
> Contact
> -------
>
More information about the dev
mailing list