On 24/08/2006, at 12:17 AM, Joakim Erdfelt wrote:
Some thoughts.
I could see the need to go back into the build history and creating
a release off of an older build to be quite likely too.
absolutely. I think Jason has talked about checking in the release
model and tagging that in the past. Future feature :)
It should really work off of a pure SCM URL + tag if needed in most
cases though.
Also, should the locking of the project be at the Continuum/
filesystem side, or on the SCM side? If scm side, we should add
supportsLock()/lock()/unlock() support to maven-scm soon.
I thought this was already implemented in the API and used by the
release plugin (and configurable).
Anyway, that would be nice but I was referring to locking on the
Continuum side to prevent builds getting into the queue when you are
using its checkout.
As for multi-module, make it context sensitive as you describe.
Example:
maven/trunk/components/ = full maven release process (multi-module)
maven/trunk/wagon/wagon-providers/ = wagon providers only release
(multi-module)
maven/trunk/jxr/ = jxr release (single module)
Yep, but we really need to revise the entire multi-module story
across Continuum. It needs to be possible to operate on them as a
unit, but also as individuals, and I don't want that concept tied to
the groups as that could hopefully be more arbitrary. But I digress...
Might prove useful on a multi-module to display/show the affected
projects/scm's on the prepare release screen as a confirmation to
the user of the release process to use.
+1
Also, about security, we definitely need to setup a ROLE for this
functionality.
Well, the work is on trunk, where there aren't any of the new roles
yet. Was the list of permissions that was started on the wiki completed?
/me puts lid back on can of worms :)
- Brett
