Difference between revisions of "Samba Release Planning"

From SambaWiki
(Fold in branch policy into release planning page)
(reorder release planning page, clarify content and avoid re-iteration.)
Line 47: Line 47:
 
|-
 
|-
 
|}
 
|}
 
== Release Branch Policies ==
 
 
Development of new features should only happen on master. Once our release manager (RM) decides a new release is ready for a first release candidate, the RM will branch off a new release branch to stabilize the release code while still allowing more experimental work to continue on master.
 
 
The release branch is created when the release candidate is cut, and is closed as soon as it is created, and should stabilize up to the release, receiving mainly bug fixes and minor changes.
 
 
Therefore, for all branches other than master, only bug fixes are allowed into the branch, according to the following procedure:
 
 
* Every bug that is to be patched in a closed branch needs to be associated with a bug report in bugzilla.
 
* The developer of the patch needs to convince at least one other developer that the bug is critical enough to be included in a closed branch.
 
* The RM applies the patch from bugzilla only if the patch has been signed off by two developers.
 
   
 
== Modes ==
 
== Modes ==
Line 73: Line 61:
   
 
This is the new upcoming release branch. It's not ready for production.
 
This is the new upcoming release branch. It's not ready for production.
  +
The branch is created when the first Release candidate becomes available for testing, otherwise development happens in our master GIT branch.
Release candidates might be available for testing.
 
   
 
=== Current Stable Release ===
 
=== Current Stable Release ===
Line 94: Line 82:
   
 
There won't be any other versions of this release series.
 
There won't be any other versions of this release series.
  +
 
== Release Branch Checkin Procedure ==
  +
 
The release branches are closed to direct checkin as soon as they are created, so for all branches, only bug fixes are allowed into the branch, according to the following procedure:
  +
 
* Every bug that is to be patched in a closed branch needs to be associated with a bug report in bugzilla.
  +
* The patch for the bug should already be in master, if possible.
  +
* Once past autobuild and in master on git.samba.org, it should be cherry-picked from master to the branch using '''git cherry-pick -x''' and '''git format-patch -1'''.
 
* The developer of the patch needs to convince at least one other developer that the bug is critical enough to be included in a closed branch.
 
* The RM applies the patch from bugzilla only if the patch has been signed off by two developers.

Revision as of 07:16, 14 October 2013

Samba Release Planning

General information

The regular Samba release cycle intends a new release series every nine month. Each release series then enters into maintenance mode when the next major release version (4.x.0) comes out as the new current stable release series. For your convenience, the next to last series will be turned into a security fixes only mode.

That means, a series is

  • nine months fully supported,
  • another nine months in the maintenance mode,
  • nine months in the security fixes only mode.

In total, each series is maintained for a period of approximately 27 months.

Example:

If 4.1 is the current release series, then 4.0 would be in maintenance mode, 3.6 would be in the security fixes only mode, and finally the support of 3.5 would be stopped with the release of 4.1.0.

Each series can have any number of desired minor release. These will be released usually every 6 weeks.

series status started maintenance security discontinued
4.2 (details) new upcoming release series
4.1 (details) current stable release series 2013-10-11
4.0 (details) maintenance mode 2012-12-11 2013-10-11
3.6 (details) security fixes only 2011-08-09 2012-12-11 2013-10-11
3.5 (details) discontinued 2010-03-01 2011-08-09 ~2012-12-17 2013-10-11
3.4 (details) discontinued 2009-07-03 2010-03-01 ~2011-08-23 2012-12-11
3.3 (details) discontinued 2009-01-27 2009-07-03 2010-03-01 2011-08-09
3.2 (details) discontinued 2008-07-02 2009-01-27 2009-08-11 2010-03-01
3.0 (details) discontinued 2003-09-24 2008-07-02 2009-01-27 2009-08-05

Modes

The mode describes the status of the release series. The following modes exist:

  • Upcoming Release
  • Current Stable Release
  • Maintenance Mode
  • Security Fixes Only Mode
  • Discontinued

Upcoming Release

This is the new upcoming release branch. It's not ready for production. The branch is created when the first Release candidate becomes available for testing, otherwise development happens in our master GIT branch.

Current Stable Release

This is the current release branch. Available bug fixes will be included in the regular bug fix releases. Bug fix releases will be shipped every six weeks usually (and on a as needed basis). New features or parameters will be added to major releases only and not within a release cycle (there might be rare exceptions).

Maintenance Mode

Maintenance mode means that there are regular bug fix releases to address major issues and security issues. Less patches are backported to this branch than to the current release series.

Security Fixes Only Mode

Only security issues will be addressed in this release series.

Discontinued

There won't be any other versions of this release series.

Release Branch Checkin Procedure

The release branches are closed to direct checkin as soon as they are created, so for all branches, only bug fixes are allowed into the branch, according to the following procedure:

  • Every bug that is to be patched in a closed branch needs to be associated with a bug report in bugzilla.
  • The patch for the bug should already be in master, if possible.
  • Once past autobuild and in master on git.samba.org, it should be cherry-picked from master to the branch using git cherry-pick -x and git format-patch -1.
  • The developer of the patch needs to convince at least one other developer that the bug is critical enough to be included in a closed branch.
  • The RM applies the patch from bugzilla only if the patch has been signed off by two developers.