If you are the current Release Manager for the Subversion project, or aspire to be, you should read and follow this procedure.
$LastChangedDate: 2006-04-03 18:57:54 +0200 (Mon, 03 Apr 2006) $
The role of the Release Manager in the Subversion project is to handle the process of getting code stabilized, packaged and released to the general public. If we were building planes, the RM would be the guy looking at the construction checklists, painting the airline logo on the fuselage, and delivering the finished unit to the customer.
As such, there is no real development associated with being an RM. All the work you have to do is non-coding: coordinating people, centralizing information, and being the public voice announcing new stable releases. A lot of the tasks that the RM has to do are repetitive, and not automated either because nobody has broken down and written the tools yet, or because the tasks require human validation that makes automation a little superfluous.
You may be thinking at this stage that the RM's duty is unglamorous, and you are kinda right. If you are looking for a position within the project that will bring fame and fortune, you're better off implementing stuff that really needs to be done on trunk. If you're looking for something that really helps people who don't care about releases focus on code, then RMing is for you.
So, you are the Release Manager. What do you need to do? This is what the rest of this document is about.
A new release branch is created for each new major and minor release. So, for example, a new release branch is created when preparing to release version 2.0.0, or version 1.3.0. However, when preparing to release 1.3.1 (a micro-version increment), the release branch created for 1.3.0 is used.
If you are preparing for a micro release, then there is no release branch to create. You just pick up where you left off in the current minor version release branch.
The time at which a new release branch needs to be created is fuzzy at best. Generally, we have a soft schedule of releasing a new minor version every 6 months. So, approximately 4 months after the previous minor release is a good time to start proposing a branch. But remember that this is flexible, depending on what features are being developed.
Once people agree that a new release branch should be made, the Release Manager creates it with the following procedure (substitute A.B with the version you're preparing, eg. 1.3, or 2.0):
Create the new release branch with a server-side copy:
svn cp http://svn.collab.net/repos/svn/trunk \
http://svn.collab.net/repos/svn/branches/A.B.x \
-m "Create the release branch for release A.B.0."
Edit subversion/include/svn_version.h on trunk and increment the version numbers there. Do not commit these changes yet.
The version number on trunk always reflects the major/minor version that will immediately follow the one for which you just created a branch (eg. 2.1.0 for the 2.0.x branch, and 1.4.0 for the 1.3.x branch).
Edit CHANGES on trunk to introduce a new section for the upcoming release. The section starts with:
Version A.B.0 (released XX XXXXX 200X, from branches/A.B.x)
http://svn.collab.net/repos/svn/tags/A.B.0
Leave the release date blank for now. It will remain this way until rolling time.
Commit both these changes with the following log message:
Increment the trunk version number, and introduce a new CHANGES
section for the upcoming A.B.0 release.
* subversion/include/svn_version.h: Increment version number.
* CHANGES: New section for A.B.0.
Once a release branch has been created, no development ever takes place there. The only changes permitted are ones made to various bookkeeping files such as STATUS, and changes merged in from trunk.
The protocol used to accept or refuse the merging of changes from trunk is of interest to all Subversion developers, and as such is documented in the release stabilization section of the hacking guide.