You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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?

  • No labels