Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <447AAFCC.7090706@apache.org>
Date: Mon, 29 May 2006 10:24:44 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Automatic releases
References: <44748DE5.50402@apache.org> <e52c3n$nd1$1@sea.gmane.org>
 <4474BCB2.6070809@apache.org> <200605261851.39399.niclas@hedhman.org>
In-Reply-To: <200605261851.39399.niclas@hedhman.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Niclas Hedhman wrote:
> On Thursday 25 May 2006 04:06, Reinhard Poetz wrote:
> 
>>But basically you're right that we have to clarify the situation in
>>general. How shall we proceed to get an answer to the question of
>>"unofficial" artifact releases? Is the pmc@cocoon in the position to decide
>>such things itself our do we have to discuss this issue with board@apache?
>>WDOT?
> 
> 
> "Automatic releases" are not a possibility, for two main reasons;
> 
>  1. Resources ; Someone pointed out how many artifacts would be created (and 
> in fact Maven will generate a bunch more, such 
> as .pom, .sha1, .md5, .pom.md5, .pom.sha1. Someone else suggested that these 
> would only exist until the next release. That is also not an option. Maven 
> relies on the fact that any build will work 'forever', as old artifacts does 
> not disappear.
> 
> 
>  2. Legal ; ALL releases from ASF MUST be under the oversight of the 
> responsible PMC. That means active insight and control of what is put into 
> the release, and vouching legally that this is a non-malicious artifact 
> suitable for consumption under a set of constraints. "Automatic releases" 
> bypasses such legal responsibility, and will be found unacceptable by the 
> Board and legal counsel.
> 
> 
> The obvious solution to the "problem" is smaller components with independent 
> release cycles, but we know that since *years*...

As I pointed out in my answer to Giacomo's mail: Also if we finally enter into a 
more frequent release cycle, let's say a release every two monthts, it could be 
too long.

                                       - o -

Let's discuss which options we have - but first look at the problem again:

What I (and obviously others) want is the possibility to use a not released 
version of an artifact in our own projects. Having a "-SNAPSHOT"-dependency is 
not an option for several reasons (snapshots are changing, you can't release 
your own artifacts if you depend on snapshots).

So what are the possible solutions:

a) Everybody learns to run the release plugin and produces artifacts himself and 
can deploy them to his own repositories. Question (to Jorg): Is this possible at 
all (IIUC the release plugin automatically tags your release in SVN)? And if 
yes, how difficult is it?

b) Find an automated way (note: I don't write "automatic release") to produce 
unoffical artifacts like "cocoon-core-2.2-r434343-NIGHTLY-BUILD.jar".

WDOT?

-- 
Reinhard P�tz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de