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

...

development

...

...

How

...

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

How new development starts

The discussion of what to resolve will happen on the list or in irc but then get populated in JIRA so that what's up for discussion gets captured. JIRA can ping the list with unresolved issues and as we are discussing the issues I think someone needs to act as secretary and capture the salient ideas in the wiki. So for the dev process stuff I created a document and steward that document to completion. I think the same would go with the integration tests where this is something that Vincent is keen to resolve so he can be the secretary for that issue. So I think the flow becomes:

...

If issues closed on the trunk should go into the branch, the release manager or other developers may choose to reopen them with the new fix for, merge and commit then close on the new target version.

Releases

Current release process

• Declare your intention to do a release through the mailing list
• Show reports on issues fixed and new features added
• Identify issues that needs to be fixed prior to the release and those that should be rescheduled
• All unit and integration tests should pass
• Use maven-docck-plugin to check for documentation standards compliance
• Deploy a snapshot for voting reference
• Call for a vote

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

...

• TODO we need to set up multiple CI processes

Working on a release branch

...

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

Calling a vote for a release

• A developer posts a message asking the list whether there are any objections to locking down for a release.
• If agreed, at this point no more issues can be assigned a fix version corresponding to the release.
• When the count goes to zero the voting for the release starts
• All external snapshots need to be resolved in advance of calling the vote and creating an RC.
• The proposal may include scope to release another dependent component, but it is highly recommended that the components be voted on separately and released in advance of the dependee.
• There should be plenty of opportunity for people to request rescheduling of issues before the vote begins. No rescheduling should be discussed in the vote unless it is exceptional circumstances.
• An RC is created and is used for people to vote on (see below)
• The vote must last at least 72 hours to give everyone a chance to give feedback.
• If there is a regression or other problem with the release, the vote is suspended until it is fixed. Other issues may be brought up during that period. Once those are resolved, the vote starts over (another 72 hours, new RC, new vote thread).

...

RCs should be made available in succession until the community is satisfied that the RC in question is of release quality. RCs should be circulated for no less then three days so that we can accurately determine if there are any defects present.
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:

...

In the interim, we use timestamped builds from CI for distributions, and timestamped snapshots for plugins.

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 use the release plug-in:

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

• TODO When these are resolved, the release should be done with release:prepare/perform instead.
• 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. One issue with moving the tag is that it will affect the POM, effectively requiring a rebuild. We probably need to prepare as if it were the final one, and recreate the tag if required.

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.

...

branch as is usually the case. However, this activity needs to be limited to important issues to avoid making the RC less stable and requiring longer testing periods.

Generating an official release

Release external dependency snapshots

For each:

• Call a vote 72 hrs. ahead
• Release the library using the release plugin
• Update any site documentation referring to the released version
• Announce the release

Call the vote

• Alllow at least 72 hrs.
• Work should be very near to completion when vote is called.

Release the libraries

• Resolve any -SNAPSHOT dependencies that are external to Maven's multimodule build.

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
• possibility of a merge file

Experimental, complex bug fix, and high-risk change branches

TODO

• TODO: Follow the Apache guidelines, which need to be finalised.

Experimental, complex bug fix, and high-risk change branches

These work like a new trunk. They are created from their intended final destination (trunk for most experimental features, the branch for complex bug fixes). It is the responsibility of the branch creator to merge changes from the original source to the experimental branch as they occur. This may well be at the end of experimental development as one big batch.

As stability is returned, the experimental branch is copied back over the original trunk after confirming all of the changes have been ported to it.

Using svnmerge to manage revisions to merge from the trunk into the release branch

The use of the svnmerge script is optional to help pick off the revisions to merge.

...

You can find the svnmerge.py script here: http://svn.collab.net/viewvc/svn/trunk/contrib/client-side/

...

If you know that a particular revision is already in sync between the trunk and the branch in question then you need to do the following so that the svnmerge script will ignore the revision when compiling a list of candidate revisions:

cd <the-branch>
svn propedit svnmerge-integrated
<start-edit>
/maven/components/trunk:1-368287,368989,369304,<your-revision>
<end-edit>
svn commit

...

Keep in mind the revisions are revisions on the trunk. So if you started in the branch and merged to the trunk then make sure it's the id of the revision on the trunk!

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