Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.213.171 as permitted sender)
Message-ID: <4E37008A.80709@gmail.com>
Date: Mon, 01 Aug 2011 12:37:46 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: Nightly snapshots
References: <4E366FB1.6080702@apache.org> <4E36BED8.9080906@gmail.com>
 <j16h9d$v1$1@dough.gmane.org> <4E36CA05.4090300@apache.org>
 <E1FFEDF8-BC1F-4548-B04D-026F51C41FE8@dslextreme.com>
 <4E36D393.6000500@apache.org> <4E36D730.1020306@gmail.com>
 <4E36DC79.4080106@free.fr>
 <30C6F72A-DD98-4ABC-AC6B-484A8C039EE2@dslextreme.com>
 <4E36EE21.5000000@gmail.com> <4E36FCAE.7000802@apache.org>
In-Reply-To: <4E36FCAE.7000802@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On 8/1/11 12:21 PM, Dennis Lundberg wrote:
> On 2011-08-01 20:19, Phil Steitz wrote:
>> On 8/1/11 10:16 AM, Ralph Goers wrote:
>>> On Aug 1, 2011, at 10:03 AM, Luc Maisonobe wrote:
>>>
>>>> Le 01/08/2011 18:41, Phil Steitz a �crit :
>>>>> On 8/1/11 9:25 AM, Emmanuel Bourg wrote:
>>>>>> Le 01/08/2011 17:57, Ralph Goers a �crit :
>>>>>>> These will just be new SNAPSHOTs so deploying a new one every
>>>>>>> evening regardless of whether it has changed should be no big
>>>>>>> deal. SNAPSHOTs without a timestamp overwrite a previous one
>>>>>>> while timestamped SNAPSHOTs should be cleaned up automatically by
>>>>>>> Nexus.
>>>>>> What's the preferred strategy? Timestamped snapshots or not?
>>>>> I think its better to have a timestamp and to create full nightlies
>>>>> - not just snapshot jars, but full timestamted source and binary
>>>>> tarballs as we used to.  FWIW, I think it is better not to push
>>>>> snaps into maven repos, but rather to place tarballs in a location
>>>>> where the sources and jars can be downloaded and unpacked.  This is
>>>>> to emphasize that the reason we are providing them is for developers
>>>>> to look at the sources and test with the jars, rather than to
>>>>> encourage "snapshot dependencies."  If the machine account problem
>>>>> has been solved from vmbuild to p.a.o, this should be pretty easy to
>>>>> automate.  I may have old scripts around somewhere that worked
>>>>> modulo this problem.
>>>> I am really on the fence with nightly builds.
>>>> I fear people will start to use them as official Apache blessed releases. They are not releases, they will change every day (or every night). We should have prominent warnings that they represent instant state and *cannot* be relied upon.
>>>>
>>>> IMHO, when people are brave enough to test development version, they should compile them by themselves. It is a way to filter out users that would not even care fixing an obvious typo that make a test fail. With nightly builds, we may end up answering many requests for more stability even in the nightly versions.
>>>>
>>>> For what purpose do we need nightly builds ? Who are the people who need nightly builds and cannot build them by themselves ?
>>> This is exactly why I am OK with SNAPSHOTs in a snapshot repository and nothing more.  This makes it convenient for users to test the latest code without requiring that they build it but since it isn't tagged most people who use Maven understand it shouldn't be relied on.
>> I agree with Luc that we need to be careful with this.  I also think
>> that the world does not revolve around maven.  Therefore, I think it
>> is a better compromise to publish nightlies in a location that is
>> clearly labelled and forces users to a) download and b) install the
>> jar or build the sources.  This is also a more friendly solution for
>> people who do not use maven.  It worked for us for years until we
>> hit the machine auth problem around the same time the ASF got
>> collectively squeamish about nightlies for the reasons that Luc
>> gives above.  I think with clear labeling we can safely do this. 
>> Ant [1] handles this fairly well.  Unfortunately, I don't think you
>> can link directly to the Continuum-generated artifacts as Jenkins
>> seems to be able to do.
> Phil, I have to respectfully disagree here.
>
> What you are saying, and I'm paraphrasing here, is that we need to make
> it as difficult as possible for our users to get hold of and use the
> latest non-stable version of commons components.

No, just that they need to know what they are doing - i.e., have it
very clear that they are downloading unreleased artifacts.  Also the
source for whatever they are downloading needs to be immediately
available.

Phil

>  We should be making it
> as easy as possible for our users to test our latest non-stable
> versions, without the user thinking that it is a release.
>
> Putting SNAPSHOT versions of our JARs into a Maven repository doesn't
> mean that only Maven can consume them. It's called a Maven repository
> because the repository layout was "invented" by the Maven project. That
> layout has since been adopted by a whole boatload of other build tools.
> There's Ivy and Maven Ant Tasks that users of Ant can use to consume
> artifacts from a Maven repository. Gradle supports Maven repositories,
> just to name a few.
>
> The SNAPSHOT repository that we have at the ASF is a separate repository
> from the releases repository. You can't just add
> commons-foo:1.1-SNAPSHOT to a build and expect it to be downloaded. You
> as the builder need to actively add the ASF SNAPSHOT repository to be
> able to consume our SNAPSHOT artifacts.
>
> The generated artifacts shouldn't be published in Continuum or Jenkins,
> those are just services that build the artifacts. When they are built
> they need to be deployed to a repository, from where they can then be
> consumed. For this we have a Nexus instance at the ASF.
>
> Adding this deploy-to-repository step is as easy as checking a check
> box and giving the URL of the repository, in Jenkins. I imagine that
> it's equally trivial in Continuum.
>
> If you need help setting up stuff in Jenkins I can help out.
>
>> Phil
>>> Ralph
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org