Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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

...

No Format
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

...

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

 

Calling a vote for a release

...

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

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

...

No Format
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!

...