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
|