You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Wendy Smoak <ws...@gmail.com> on 2006/11/23 00:01:16 UTC

Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:

> In order to use the release plugin, I have to decide to go for it, and
> call a particular source tree releasable. This may sound trivial, but it
> isn't. How do I decide that?

We've been struggling with the same issue inside Apache, where our
policies require a vote on the actual artifacts that will be released.

I haven't seen anything recently, but last month we had a discussion
about changing the release process to include a "staging" or
"proposal" phase.

So it would be release:prepare, release:propose, then either
release:accept or release:clean

In between propose and accept is when your QA department would do
their work... and if accepted, the exact artifacts they've tested will
be promoted to the release repository.

Here's the thread:
http://www.nabble.com/Maven-and-the-Apache-processes...-t2430753s177.html#a6800959

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

Posted by Wendy Smoak <ws...@gmail.com>.
On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:

> > In between propose and accept is when your QA department would do
> > their work... and if accepted, the exact artifacts they've tested will
> > be promoted to the release repository.
>
> This is I think where the problem is: if the "promotion" involves a
> rebuild,
...

Promotion does *not* involve a rebuild.

Like you, Apache projects need to examine (and vote) on the *exact*
artifacts that get released to the public.  Maven's current release
process doesn't allow us to (easily) do this.

The new process (still under discussion as far as I know...) involves
proposing a release, examining it, and then either accepting it or
not.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

Posted by Christian Goetze <ch...@sensage.com>.
Wendy Smoak wrote:

> On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
>
>> In order to use the release plugin, I have to decide to go for it, and
>> call a particular source tree releasable. This may sound trivial, but it
>> isn't. How do I decide that?
>
>
> We've been struggling with the same issue inside Apache, where our
> policies require a vote on the actual artifacts that will be released.
>
> I haven't seen anything recently, but last month we had a discussion
> about changing the release process to include a "staging" or
> "proposal" phase.
>
> So it would be release:prepare, release:propose, then either
> release:accept or release:clean
>
> In between propose and accept is when your QA department would do
> their work... and if accepted, the exact artifacts they've tested will
> be promoted to the release repository.

This is I think where the problem is: if the "promotion" involves a 
rebuild, especially one where the source code changes - even if it's 
only the version string, then you have created uncertainty and devalued 
the testing effort of QA. That's why I want every build to be done as if 
it was a release, and only call something a release by granting access 
to it.

This design principle is fundamental in the build system into which I'm 
attempting to embed maven - hence my problem :)

>
> Here's the thread:
>
Thanks for the link. I'll read it....


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org