Difference between revisions of "Xen Project Maintenance Releases"

From Xen
(Stable Maintenance Branches)
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= Stable Maintenance Branches =
 
= Stable Maintenance Branches =
   
Each new Xen release X.Y.0 starts a new stable maintenance branch.
+
Each new Xen Project release X.Y.0 starts a new stable maintenance branch.
   
  +
Each branch is maintained in the main [http://xenbits.xen.org/gitweb/?p=xen.git xen.git] repository in a ''stable-X.Y'' branch. See [[Xen Project Repositories]] for more information about the current branches.
Each such branch is in its own mercurial repository
 
xen-X.Y-testing.hg. See [[Xen Repositories]] for more information
 
about the current branches.
 
   
Releases are intended to happen roughly every 3 months. The first
+
Releases are intended to happen roughly every '''4 months'''. The first
 
release on a stable branch is often sooner and as the branch reaches
 
release on a stable branch is often sooner and as the branch reaches
 
the end of its life the interval may be longer.
 
the end of its life the interval may be longer.
   
  +
In general XenProject.org supports stable branches for '''18 months full support plus 18 months security fixes'''. When a new X.Y.0 release is made there is usually one more
In general Xen.org supports the two most recent stable branches at any
 
given time. When a new X.Y.0 release is made there is usually one more
 
 
release on the to-be-retired stable branch to mop up any loose patches
 
release on the to-be-retired stable branch to mop up any loose patches
 
sitting in the repository at which point the branch is retired.
 
sitting in the repository at which point the branch is retired.
 
For example at the time of writing we are in the 4.3 development cycle
 
and are supporting two stable branches: 4.1-testing and
 
4.2-testing. After 4.2.0 was released there was one more release in
 
the 4.0-testing stream (4.0.4) and then the 4.0 branch was retired.
 
   
 
= Stable Branch Maintainer =
 
= Stable Branch Maintainer =
Line 25: Line 17:
 
Each stable branch has a maintainer who is nominated/volunteers
 
Each stable branch has a maintainer who is nominated/volunteers
 
according to the ''Maintainer Election'' process described in the
 
according to the ''Maintainer Election'' process described in the
[http://www.xen.org/projects/governance.html project governance]
+
[http://www.xenproject.org/governance.html project governance]
 
document. This will resulting in the MAINTAINERS file in the relevant
 
document. This will resulting in the MAINTAINERS file in the relevant
 
branch being patched to include the maintainer.
 
branch being patched to include the maintainer.
   
For the branches maintained by Xen.org one of the regular xen-unstable
+
For the branches maintained by XenProject.org one of the regular xen-unstable
 
committers or maintainers would usually step up as maintainer. However
 
committers or maintainers would usually step up as maintainer. However
 
other community members can also step up to maintain a stable release,
 
other community members can also step up to maintain a stable release,
Line 41: Line 33:
 
= Stable Branch Patch Inclusion Policy =
 
= Stable Branch Patch Inclusion Policy =
   
No new development happens in the X.Y-testing branches, instead
+
No new development happens in the ''stable-X.Y'' branches, instead
changesets are backported from xen-unstable. Where this is not possible
+
changesets are backported from ''xen-unstable'' (AKA the master branch). Where this is not possible
 
(perhaps unstable has moved on such that the patch cannot be applied or
 
(perhaps unstable has moved on such that the patch cannot be applied or
 
the approach used in unstable is otherwise not valid for the stable
 
the approach used in unstable is otherwise not valid for the stable
Line 64: Line 56:
 
As well as changesets identified by the branch maintainer as being suitable
 
As well as changesets identified by the branch maintainer as being suitable
 
for backport changes can also be nominated for inclusion in the stable
 
for backport changes can also be nominated for inclusion in the stable
branch by making a request to the stable maintainer on xen-devel
+
branch by making a request to the stable maintainer on the [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel mailing list]
 
either by noting it as such in the submission of the original patch to
 
either by noting it as such in the submission of the original patch to
 
xen-unstable or by a subsequent explicit email to xen-devel.
 
xen-unstable or by a subsequent explicit email to xen-devel.
Line 76: Line 68:
 
[[Category:Xen]]
 
[[Category:Xen]]
 
[[Category:Project]]
 
[[Category:Project]]
  +
[[Category:Developers]]

Latest revision as of 12:29, 10 November 2015

Stable Maintenance Branches

Each new Xen Project release X.Y.0 starts a new stable maintenance branch.

Each branch is maintained in the main xen.git repository in a stable-X.Y branch. See Xen Project Repositories for more information about the current branches.

Releases are intended to happen roughly every 4 months. The first release on a stable branch is often sooner and as the branch reaches the end of its life the interval may be longer.

In general XenProject.org supports stable branches for 18 months full support plus 18 months security fixes. When a new X.Y.0 release is made there is usually one more release on the to-be-retired stable branch to mop up any loose patches sitting in the repository at which point the branch is retired.

Stable Branch Maintainer

Each stable branch has a maintainer who is nominated/volunteers according to the Maintainer Election process described in the project governance document. This will resulting in the MAINTAINERS file in the relevant branch being patched to include the maintainer.

For the branches maintained by XenProject.org one of the regular xen-unstable committers or maintainers would usually step up as maintainer. However other community members can also step up to maintain a stable release, typically once Xen.org no longer does so.

The stable branch maintainer is responsible for identifying suitable candidates for inclusion in the stable branch both according to their own judgment and by evaluating requests from the community (see below).

Stable Branch Patch Inclusion Policy

No new development happens in the stable-X.Y branches, instead changesets are backported from xen-unstable (AKA the master branch). Where this is not possible (perhaps unstable has moved on such that the patch cannot be applied or the approach used in unstable is otherwise not valid for the stable branch) then a specific fix can be created for the stable branch. However it is a requirement that the issue will always be fixed in unstable first (this is to avoid regressions on the next major release).

In general only bug fixes are accepted into stable branches and new features are not normally accepted. (There can be exceptions, e.g. it was agreed that 4.2.1 would take a more relaxed approach to features which improved xl compatibility with xm). As time passes each stable branch becomes more conservative and the barrier to accepting a patch for backport becomes higher.

Changesets are included in the stable branch at the discretion of the branch maintainer.

Requesting A Backport

As well as changesets identified by the branch maintainer as being suitable for backport changes can also be nominated for inclusion in the stable branch by making a request to the stable maintainer on the xen-devel mailing list either by noting it as such in the submission of the original patch to xen-unstable or by a subsequent explicit email to xen-devel.

Backport requests should always be copied to the relevant stable maintainer. In addition as part of the the stable release process the stable maintainer will send one or more requests to xen-devel soliciting suggestions for patches which should be included.