Page History

...

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.

...