Page History

...

All new features 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 should be applied to. There may be rare cases where a new feature 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.

Releases

Creating a release branch

...

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

...

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

Creating release candidates (RCs) from a release branch

...

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

How to integrate bug fixes into a release branch

If bugs are found in the release, then the fixes should be applied to the trunk and then immediately be applied to the release branch. The only time this would no apply is when there are features in the branch that are not present in the trunk i.e. deprecated features.

/----------/

This page serves as the touchstone for the development process that is used by Maven to manage branches and the trunk during the development leading up to releases.

This thread never really got rounded up, so I thought I'd summarise some points we seemed to be in agreeance on. Please vote +1 for all, or +1/+0/-1 for every item.

• use of the flying fish technique (ie bugfix only release goes over to /branches/2.0.x)
  • we should merge at each point release (2.0.1, 2.0.2) back to trunk
  • can do interim merges if there are long time lines on those releases
  • we need to set up multiple CI processes
• no alphas or betas on 2.0.x releases
• current version is always <final release>-SNAPSHOT, eg 2.1-SNAPSHOT
• 2.1 cycle will have betas (maybe alphas), which are labelled at release time (release plugin to accommodate)
• RC's are the actual build. It will report version "2.0", and is differentiated from the actual final release (if different), by the build timestamp. If the RC is not suitable for any reason, we remove the old tag, and redo the release
• we will setup one new JIRA project per plugin (prefix with just M, won't be reusing the m1 projects, and we'll move all existing issues to there even if closed - based on component)

The same should also apply to Continuum.

If we agree on this, then the first step is:
svn cp https://svn.apache.org/repos/asf/maven/components/trunk https://svn.apache.org/repos/asf/maven/components/branches/2.0.x

and everyone svn switches to that if they are doing core bugfixes. John - can you do this?

...

• moving into a API breaking version there will be alphas, betas i.e. 2.1-alpha-1
• we need to set up multiple CI processes

some things I have written (jesse) general notes on subversion, branching and tagging, dumped here at the behest of jason...cut and copy up as needed..

...