Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - No svn revision corresponding to hadoop-0.23.0-src.tar.gz contents?


Copy link to this message
-
Re: No svn revision corresponding to hadoop-0.23.0-src.tar.gz contents?
Steve Loughran 2011-11-24, 12:41
On 23/11/11 04:50, Scott Carey wrote:
>
> On 11/22/11 8:39 PM, "Scott Carey"<[EMAIL PROTECTED]>  wrote:
>
>> My experience with Maven differs, see below:
>>
>> On 11/22/11 3:40 PM, "Andrew Bayer"<[EMAIL PROTECTED]>  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