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
-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
>> 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
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