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?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
