hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: No svn revision corresponding to hadoop-0.23.0-src.tar.gz contents?
Date Thu, 24 Nov 2011 12:41:15 GMT
On 23/11/11 04:50, Scott Carey wrote:
>
> On 11/22/11 8:39 PM, "Scott Carey"<scott@richrelevance.com>  wrote:
>
>> My experience with Maven differs, see below:
>>
>> On 11/22/11 3:40 PM, "Andrew Bayer"<andrew.bayer@gmail.com>  wrote:
>>
>>> Hi Arun -
>>>
>> > From my Maven experience, I'd strongly suggest that branch-0.23 should be
>>> 0.23.1-SNAPSHOT
>>
>> This is standard maven practice ('rename where you came from'), and is
>> where I differ.
>> IMO the branch should have a stable version, 0.23.x-SNAPSHOT, why decide
>> that the next version must be 0.23.1 before the branch is even cut?  Why
>> does creating a branch change the contents of where you branched _from_
>> rather than where you branch _to_ ?
>
> There is one big reason I like to have my svn path to maven version
> relationship stable.
>
> Many developer tools and IDE's require manual intervention if the maven
> versions of the products they are sitting on top of change.
> Users have to re-import or initialize their IDE's (especially eclipse with
> m2e or maven:eclipse).
> Why should the act of cutting a branch from trunk affect trunk devs?
> Why should the act of cutting a tag or branch from a branch affect devs
> working on that branch?
> In neither case did the trunk or branch change in any way.  Therefore IMO
> the pom should not change either.

I'd prefer to see some stable artifacts with names like 0.23.0-alpha1, 
or 0.20.0-r5545 where the SVN revision is included

Why?

Because -SNAPSHOT is pretty much meaningless.

1. At build time it means "the last published version that M2 could be 
bothered to download"

2. It's extra meaningless when someone files a bugrep against a SNAPSHOT 
version. Which snapshot? Today's? Yesterdays?

3. downstream projects need stable artifacts to build and release 
against, so I can say "here is a version that includes the 0.23.0-r5545 
alpha release" rather than "here is a version that includes some 
snapshot artifact whose provenance is indeterminate.

4. downstream builds will be utterly unreplicable. Just because 
everything compiled on the box at time t1=today, if you take my source 
tree and try to build at time t2 != t1 it may not compile, let alone work.

I propose that every alpha/beta release has a set of artfacts published 
to the stable maven repo with the same version counter as the .tar.gz 
artifacts. That way I can set hadoop.version=0.23.0-r5545 and have a 
stable build/release process.

IDEs? Not my problem. I can do an ant ivy-retrieve and get the current 
artifact set if I want that; for Hadoop I'm more likely to mount the 
live svn branch, so that if I get a stack trace I can not only go into 
the source, I can change things. For everyone else in my group who 
builds, they can get the artifact and src jar from the maven repositories

Mime
View raw message