Development Process

This document serves as the touchstone for the development process that is used by the Maven project to manage branches and the trunk during the development leading up to releases.
In particular the following will be addressed:

• New features development
• Releases
  • Creating a release branch
  • Working on a release branch
  • Creating release candidates (RCs) from a release branch
  • Soak period for RCs
  • How to integrate bug fixes into an RC
  • Generating an official release
  • How to integrate bug fixes into a release branch
• Experimental, complex bug fix, and high-risk change branches

The terminology used here is somewhat SVN specific as that is the 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 development should be applied to. There may be rare cases where a new 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 and this is the responsbility of the release manager. So developers can focus on improvements in the trunk and the burden of merging will be the task of the release manager. New features or improvements should never originate from a branch

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. A release branch is a long-lived branch from which all the releases for a non-API breaking versions are made. So you would release 2.0, 2.0.1, 2.0.2 of a project from a 2.0.x branch and likewise you would release 2.1, 2.1.1, 2.1.2 from a 2.1.x branch.
• Make sure that 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.

To create a branch to prepare for a release us the following command:

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

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

Working on a release branch

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 that finally makes the cut as the release should 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:

• TODO We need a staging repository where the RCs can be placed so that failed RC attempts don't pollute a release repository
• TODO 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
...

• TODO We need to figure out the process of how we tag the RCs, probably don't need to keep them. Maybe just roll over the previous one until the RC is good enough to release.

How to integrate bug fixes into an RC

If bugs are found in the RCs, then the fixes should be applied to the trunk and then it will be up to the release manager to integrate the fixes into the release branch.

• TODO Some tag in the SCM message might be useful to give a hint to the release manager, or a tool, as to which revisions need to be merged.

Generating an official release

When you are ready to create a release you need to create a tag and release with the release plug-in:

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

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

How to integrate bug fixes into a release branch

If bugs are found in the release then the fixes should be applied to trunk and then it will be up to the release manager to integrate the fixes into 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.

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

• 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..

A little bit about subversion. Tags and branches are functionally the same, and are merely symbolic. making a branch or a tag is not earmarking the file in the repository with a little indicator like it is in cvs, it is logically a copy of the file at that particular revision. with that in mind, tagging is no longer a seperate process from merging...they are no different. The act of tagging doesn't exist. Instead you merge a given changeset from one location to another. svn maintains some amount of knowledge of the file that it was copied from, but not what given changeset was merged into it when.

Common development will take place on the trunk. Work that embody any kind of size or impacts a large array of objects should be done on a special development branch pulled by the developer/s. A note on these branches, I really don't think they should be worked out outside of a couple of weeks...the longer that people spend working on and committing on a branch and not merging that work back onto the trunk the more annoying it will get to finally do the merge. Especially in the infancy of people actually working with branching and merging....it is critical to not let development branches like this get out of hand. If something is going to take over two weeks of development I would consider breaking that development up into multiple phases which each phase being something that can be merged back to the trunk. If API's are going to change, get them changed sooner then later.

There are a number of fundamental things that we need to manage ourselves as developers.

1. my work tramples your previous work
2. my work is getting pushed up the release chain before yours
3. your in a heap of trouble if promoting your changes carries sometime along with it that it shouldn't

first off, work is getting done on the trunk, my commits for project X are getting committed as we go along as I development it on my personal development instance. I feel (or am told perhaps) that it is time to get my stuff moved to QA. Like a good developer I have maintained a list of the changesets that embody my project X, say r100, r105, r106, r109, and r140.

I checkout the release branch and begin merging the changesets from the trunk...all the change sets get shoved into my release branch instance at the same time. I now commit these change sets to the release branch and get me a new r#, say r200 for this instance. I have now aggregated the 5 commits I had made on the trunk into 1 changeset on the release branch. I edit a file called MERGE on the release branch and note that changeset number, the project, and hopefully the jira issue that relates to it. The work is then built and snapshotted and tested... perhaps I have a bugfix or 2 or 3...that get merged to the release branch and added to the MERGE file as changesets representing that Project X of work.

This approach has benefits since it really represents the aggregation of work into larger changesets to deployment. The only side effect it really has is that it doesn't solve the 'my work effects yours, but mine is going first'...but nothing so far addresses that, and if the MERGE file is consistently up to date it can be mined by an external process to protect us I believe. an external process be told what changesets are wanted to be moved from qa to staging and interrogate svn to determine if the changeset for project X masks any files from another changeset being monitored in that same file....this lets us monitor subproject dependencies programattically which would rock.

Pros:

• potential merging of changed code only between developer branches and the trunk
• merging is between trunk and release branches, never between release branch to release branch
• jira tasks for things like javadoc additions and maintanence tasks can be grep'd out of these files, piped through cut, sort and diff to automagically give you changesets to merge to a release tag using xargs
• SIMPLE! if developers keep to the process then releases should be quite simple, just a matter of applying a set of changesets

Cons:

• someone might forget to mark a changeset in the MERGE file, beatings can minimize this though
• same con as everything else, you if changeset X touchs things that changeset Y did...Y has to go forward first, or both have to go...but no system addresses that

another potential mechanism...or naming convention, kicked around a couple of weeks ago.

-SNAPSHOT development suffix for version tags.
-STABLE bugfix suffix for released versions
-RELEASE tag suffix for a released versions

so 2.0-RELEASE is a svn tag that is immutable, it is set once for a set of code, 2.0-STABLE becomes the bugfix branch for the 2.0-RELEASE...and people can track that -STABLE release for something they are assured to be solid and stable...2.1-SNAPSHOT would be development code, released periodically as per whatever rules govern development code release, as needed perhaps

Useful links

http://www.asterisk.org/developers/svn-branching-merging
http://www.reactos.org/wiki/index.php/Best_practices_for_working_with_branches
http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING
http://svn.collab.net/viewcvs/svn/trunk/contrib/client-side/
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html