Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


+
Andrew Bayer 2011-11-22, 21:43
+
Arun C Murthy 2011-11-22, 23:32
+
Andrew Bayer 2011-11-22, 23:40
+
Arun C Murthy 2011-11-22, 23:44
+
Andrew Bayer 2011-11-22, 23:51
+
Arun C Murthy 2011-11-23, 00:12
+
Andrew Bayer 2011-11-23, 00:31
+
Scott Carey 2011-11-23, 04:39
+
Scott Carey 2011-11-23, 04:50
Copy link to this message
-
Re: No svn revision corresponding to hadoop-0.23.0-src.tar.gz contents?
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
+
Luke Lu 2011-11-24, 19:00
+
Tom White 2011-11-23, 00:33
+
Andrew Bayer 2011-11-23, 00:41
+
Arun C Murthy 2011-11-23, 01:03
+
Scott Carey 2011-11-23, 04:46
+
Doug Cutting 2011-11-23, 20:28
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB