commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: Nightly snapshots
Date Mon, 01 Aug 2011 19:21:18 GMT
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. 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
> 
> 


-- 
Dennis Lundberg

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


Mime
View raw message