Page History

...

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
  • Where new development starts
• 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

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 (if that's ok Vincent). So I think the flow becomes

• everyone pushes issues they want resolved into JIRA
• we prioritize a short list to work on in a particular week (or whatever), we can use votes or just decide amongst ourselves

with that short list we:

• pick the issue at hand
• burst of discussion on the list
• secretary captures the salient points
• offers up the document for review
• go back to discussion/capture/review until complete
• a final document then accompanies the resolution and the issue is closed

Where new development starts

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

...