Page History

...

The terminology used here is somewhat SVN specific as that is the tool SCM the Maven project uses. At some point we would like to generalize these strategies for all SCMs and integrate these strategies into general tools where Maven SCM can deal with the operations outlined here in an SCM independent fashion.

New

...

development

All new development, whether new features or general improvements, should be integrated into the latest revision or the trunk. Once a new feature is implemented and integrated into the trunk it can then be decided which branches the new features development should be applied to. There may be rare cases where a new feature development only applies to a particular branch but in general all new features go to the trunk first and disseminated from there. The important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake. Changes should be kept in sync at all times where possible.

...

The responsibility of merging changes from the trunk to the various branches is the responsbility of the release manager for the branch in question. To be clear if you are committing changes to trunk do not merge your changes into any of the release branches.

Releases

Creating a release branch

• A release branch should be made well in advance of the release to allow for stabilzation of the release and the preparation of RCs
• Make sure that everyone has all developers checked in their local modifications before the branch is created.
• Copy using URLs as everything will occur on the server and be faster.

...

svn copy -m "Create Maven 2.0.x branch" svn://svn.apache.org/repos/asf/maven/components/trunk svn://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x

Working on a release branch

mvn release:prepare
...
mvn release:perform
...

Working on a release branch

To To work on a release branch you can either checkout the branch or switch and existing working copy to the branch. It is probably easier to checkout the branch in a different directory so that you can work on the trunk and branch at the same time.

svn co svn://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x

...

Creating release candidates (RCs) from a release branch

RCs should be made available in succession until the community is satisfied that the RC in question is of release quality. The RC should be tagged and a standard release using that finally makes the cut as the release plugin should follow.

...

be used as it was originally built so the RCs will be named as if they were the final release. This means that we have a few technical issues to resolve:

• We need a staging repository where the RCs can be placed so that failed RC attempts don't pollute a release repository
• We need a reliable way of moving the successful RC from the staging repository to the release repository. This is an intended feature for the Repository Manager but we may need a stop-gap solution until the Repository Manager is ready for production use.

...

Soak period for RCs

RCs should be circulated for no less then three days so that we can accurately determine if there are any defects present. When you are ready to release the RC create the tag and then release with the release plug-in:

svn copy -m "Tag release 2.0.3" svn://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x svn://svn.apache.org/repos/asf/maven/components/tags/maven-2.0.3-rc1

...

mvn release:prepare
...
mvn release:perform
...

How to integrate bug fixes into an RC

...