When a release is ready to go, release manager (RM) puts
forward a release plan as per standard Apache process, including
dates. This gets VOTEd on by the committers. During this period the
trunk is still the only relevant source base.
As soon as a release is approved (or even before), RM should
add the new version into JIRA as a target.
At the point where we would normally do the "code freeze" for a
release, the RM cuts a branch named for the release. This branch is
where the release candidates and releases will happen.
Ideally a release branch is only around for a week or maybe two
before the release happens.
The only things that should EVER get checked into the release
branch are - 1) bug fixes targeted at the release, 2)
release-specific updates (documentation, SNAPSHOT removal, etc). In
particular new functionality does not go here unless it is a
solution to a JIRA report targeted at the release.
Normal development continues on the trunk.
Dependencies and branches
The trunk should always be "cutting edge" and as such should
usually be pointing at SNAPSHOT versions of all dependencies. This
allows for continuous integration with our partner projects.
Soon after a release branch is cut, the RM is responsible for
removing ALL dependencies on SNAPSHOT versions and replacing them
with officially released versions. This change happens only on the
release branch.
Managing change and issue resolution with a release branch
The RM goes through JIRA issues and sets "fix for" to point to
both "NIGHTLY" and the new branched release number for the fixes
that are targeted for the release after the branch is cut.
In general, the assignee/coder fixes JIRA issues or makes other
changes *on the trunk*. If the JIRA issue is targeted at the
release, or upon coder's discretion, they then merge the fix over
to the release branch.
This way the trunk is ALWAYS up-to-date, and we don't have to
worry about losing fixes that have only been made on the release
branch.
When the assignee resolves an issue, they confirm it's been
fixed in both branches, if appropriate.
Checking changes into the branch
If bug fixes are needed later for a release which has long
since happened (to fix user issues, etc), those fixes generally
should also happen on the trunk first assuming the problem still
exists on the trunk.
There are only two cases where we would ever check anything
into the branch without first checking it into the trunk. 1)
Release specific items (release number references, release notes,
removal of SNAPSHOTs), and 2) if the trunk has moved on in some
incompatible way.