Hi all -

I've been unable to find a revision in svn that actually corresponds
directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
everything on branch-0.23, everything on branch-0.23.0, everything on the
rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this something
which could be fixed?

Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?

A.

Andrew,
On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:

> Hi all -
>
> I've been unable to find a revision in svn that actually corresponds
> directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
> tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
> everything on branch-0.23, everything on branch-0.23.0, everything on the
> rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this something
> which could be fixed?
>

It wasn't clear at that time, so I used 'mvn versions:set' to create the release. I could go ahead and commit, Tom?

I've documented that in http://wiki.apache.org/hadoop/HowToReleasePostMavenization.

> Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?

That's easy to do, but, again I'm sketchy about when we change it to 0.23.1 - should that be done in a branch-0.23.1?

Arun

Hi Arun -

>From my Maven experience, I'd strongly suggest that branch-0.23 should be
0.23.1-SNAPSHOT - without question, nothing should be 0.23.0-SNAPSHOT after
0.23.0 proper has shipped. That's just confusing and wrong. =) branch-0.23
should probably always point to the next SNAPSHOT on the 0.23.x line -
i.e., once branch-0.23.1 is cut, branch-0.23 should change to
0.23.2-SNAPSHOT, etc. The SNAPSHOT version should always be looking
forward, not looking back.

I've worked around the svn issue for the moment, but definitely for 0.23.1,
it'd be best to have the release, including POM versioning etc, match up
with source control.

A.

On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

> Andrew,
>
>
> On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
>
> > Hi all -
> >
> > I've been unable to find a revision in svn that actually corresponds
> > directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
> > tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
> > everything on branch-0.23, everything on branch-0.23.0, everything on the
> > rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this
> something
> > which could be fixed?
> >
>
> It wasn't clear at that time, so I used 'mvn versions:set' to create the
> release. I could go ahead and commit, Tom?
>
> I've documented that in
> http://wiki.apache.org/hadoop/HowToReleasePostMavenization.
>
> > Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
>
> That's easy to do, but, again I'm sketchy about when we change it to
> 0.23.1 - should that be done in a branch-0.23.1?
>
> Arun

Agree, about moving branch-0.23 to 0.23.1-SNAPSHOT, I'll do that asap.

We don't really create branch-0.23.1, maybe we should - I'll do that henceforth and also add these to the HowToRelease page.

Thanks!

Arun

On Nov 22, 2011, at 3:40 PM, Andrew Bayer wrote:

> Hi Arun -
>
> From my Maven experience, I'd strongly suggest that branch-0.23 should be
> 0.23.1-SNAPSHOT - without question, nothing should be 0.23.0-SNAPSHOT after
> 0.23.0 proper has shipped. That's just confusing and wrong. =) branch-0.23
> should probably always point to the next SNAPSHOT on the 0.23.x line -
> i.e., once branch-0.23.1 is cut, branch-0.23 should change to
> 0.23.2-SNAPSHOT, etc. The SNAPSHOT version should always be looking
> forward, not looking back.
>
> I've worked around the svn issue for the moment, but definitely for 0.23.1,
> it'd be best to have the release, including POM versioning etc, match up
> with source control.
>
> A.
>
> On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
>
>> Andrew,
>>
>>
>> On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
>>
>>> Hi all -
>>>
>>> I've been unable to find a revision in svn that actually corresponds
>>> directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
>>> tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
>>> everything on branch-0.23, everything on branch-0.23.0, everything on the
>>> rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this
>> something
>>> which could be fixed?
>>>
>>
>> It wasn't clear at that time, so I used 'mvn versions:set' to create the
>> release. I could go ahead and commit, Tom?
>>
>> I've documented that in
>> http://wiki.apache.org/hadoop/HowToReleasePostMavenization.
>>
>>> Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
>>
>> That's easy to do, but, again I'm sketchy about when we change it to
>> 0.23.1 - should that be done in a branch-0.23.1?
>>
>> Arun

By "create branch-0.23.1", I guess I'm referring to when the release branch
itself is cut, then. =)

A.

On Tue, Nov 22, 2011 at 3:44 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

> Agree, about moving branch-0.23 to 0.23.1-SNAPSHOT, I'll do that asap.
>
> We don't really create branch-0.23.1, maybe we should - I'll do that
> henceforth and also add these to the HowToRelease page.
>
> Thanks!
>
> Arun
>
> On Nov 22, 2011, at 3:40 PM, Andrew Bayer wrote:
>
> > Hi Arun -
> >
> > From my Maven experience, I'd strongly suggest that branch-0.23 should be
> > 0.23.1-SNAPSHOT - without question, nothing should be 0.23.0-SNAPSHOT
> after
> > 0.23.0 proper has shipped. That's just confusing and wrong. =)
> branch-0.23
> > should probably always point to the next SNAPSHOT on the 0.23.x line -
> > i.e., once branch-0.23.1 is cut, branch-0.23 should change to
> > 0.23.2-SNAPSHOT, etc. The SNAPSHOT version should always be looking
> > forward, not looking back.
> >
> > I've worked around the svn issue for the moment, but definitely for
> 0.23.1,
> > it'd be best to have the release, including POM versioning etc, match up
> > with source control.
> >
> > A.
> >
> > On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]>
> wrote:
> >
> >> Andrew,
> >>
> >>
> >> On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
> >>
> >>> Hi all -
> >>>
> >>> I've been unable to find a revision in svn that actually corresponds
> >>> directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
> >>> tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
> >>> everything on branch-0.23, everything on branch-0.23.0, everything on
> the
> >>> rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this
> >> something
> >>> which could be fixed?
> >>>
> >>
> >> It wasn't clear at that time, so I used 'mvn versions:set' to create the
> >> release. I could go ahead and commit, Tom?
> >>
> >> I've documented that in
> >> http://wiki.apache.org/hadoop/HowToReleasePostMavenization.
> >>
> >>> Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
> >>
> >> That's easy to do, but, again I'm sketchy about when we change it to
> >> 0.23.1 - should that be done in a branch-0.23.1?
> >>
> >> Arun
>
>

On Nov 22, 2011, at 3:51 PM, Andrew Bayer wrote:

> By "create branch-0.23.1", I guess I'm referring to when the release branch
> itself is cut, then. =)
>

Like I said, we haven't actually been creating the 0.x.y branch ever... so, you won't find a 0.20.2 branch or 0.18.1 branch.

That said, it's something we need to do given that our votes run for 7 days now. I'll do that henceforth and update the HowToRelease wiki too.

Arun

Cool. I've run into some other problems building from the released source
tarball (missing aop.xml files) but I believe there's already a JIRA for
that.

A.

On Tue, Nov 22, 2011 at 4:12 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:

>
> On Nov 22, 2011, at 3:51 PM, Andrew Bayer wrote:
>
> > By "create branch-0.23.1", I guess I'm referring to when the release
> branch
> > itself is cut, then. =)
> >
>
> Like I said, we haven't actually been creating the 0.x.y branch ever...
> so, you won't find a 0.20.2 branch or 0.18.1 branch.
>
> That said, it's something we need to do given that our votes run for 7
> days now. I'll do that henceforth and update the HowToRelease wiki too.
>
> Arun
>
>

On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
> Andrew,
>
>
> On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
>
>> Hi all -
>>
>> I've been unable to find a revision in svn that actually corresponds
>> directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
>> tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
>> everything on branch-0.23, everything on branch-0.23.0, everything on the
>> rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this something
>> which could be fixed?
>>
>
> It wasn't clear at that time, so I used 'mvn versions:set' to create the release. I could go ahead and commit, Tom?
>
> I've documented that in http://wiki.apache.org/hadoop/HowToReleasePostMavenization.

I think 'mvn versions:set' should be called (and changes committed)
before creating the release candidate tag. I.e. after step 4 of
'Updating Release Branch'  on that wiki page.

Cheers,
Tom

>
>> Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
>
> That's easy to do, but, again I'm sketchy about when we change it to 0.23.1 - should that be done in a branch-0.23.1?
>
> Arun

That sounds like best practices for a situation where you're using Maven
but not using the release plugin, yeah.

A.

On Tue, Nov 22, 2011 at 4:33 PM, Tom White <[EMAIL PROTECTED]> wrote:

> On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]>
> wrote:
> > Andrew,
> >
> >
> > On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
> >
> >> Hi all -
> >>
> >> I've been unable to find a revision in svn that actually corresponds
> >> directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
> >> tarball all have <version>0.23.0</version>, but the release-0.23.0 tag,
> >> everything on branch-0.23, everything on branch-0.23.0, everything on
> the
> >> rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this
> something
> >> which could be fixed?
> >>
> >
> > It wasn't clear at that time, so I used 'mvn versions:set' to create the
> release. I could go ahead and commit, Tom?
> >
> > I've documented that in
> http://wiki.apache.org/hadoop/HowToReleasePostMavenization.
>
> I think 'mvn versions:set' should be called (and changes committed)
> before creating the release candidate tag. I.e. after step 4 of
> 'Updating Release Branch'  on that wiki page.
>
> Cheers,
> Tom
>
> >
> >> Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
> >
> > That's easy to do, but, again I'm sketchy about when we change it to
> 0.23.1 - should that be done in a branch-0.23.1?
> >
> > Arun
>

On Nov 22, 2011, at 4:33 PM, Tom White wrote:
> I think 'mvn versions:set' should be called (and changes committed)
> before creating the release candidate tag. I.e. after step 4 of
> 'Updating Release Branch'  on that wiki page.

Furthermore, we need to create a branch for the actual version e.g. branch-0.23.1 where we commit it. Then, branch-0.23 should have version set to 0.23.2-SNAPSHOT.

I'll update the wiki to reflect these.

Arun

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

> - without question, nothing should be 0.23.0-SNAPSHOT after
>0.23.0 proper has shipped.
Absolutely.

>That's just confusing and wrong. =) branch-0.23
>should probably always point to the next SNAPSHOT on the 0.23.x line -
>i.e., once branch-0.23.1 is cut, branch-0.23 should change to
>0.23.2-SNAPSHOT, etc. The SNAPSHOT version should always be looking
>forward, not looking back.

Granted, I haven't even pushed these ideas on the project I'm a PMC member
of (Avro), but I've never been very comfortable with picking the version
of a release before its branch / tag is even cut.  On a stable branch, you
might know that when you cut 0.23.2, the next version will be called
0.23.3, so renaming to 0.23.3-SNAPSHOT makes sense.  But what if it is
otherwise?
In the case of trunk, the next might be a minor version or major version
change, picking which it is up front is not be ideal.  It also complicates
the release process, having to rename both the release (removing
-SNAPSHOT) and the place you tagged from (upping the version number).  Why
not just change one thing?

svn path  |  maven version
trunk/  |  trunk-SNAPSHOT
branches/0.23.x   |  0.23.x-SNAPSHOT
tags/0.23.0   |   0.23.0

you can always branch from a tag, so there isn't need for a branch for
every tag either.  That is just clutter.

>
>I've worked around the svn issue for the moment, but definitely for
>0.23.1,
>it'd be best to have the release, including POM versioning etc, match up
>with source control.

Agree.

>
>A.
>
>On Tue, Nov 22, 2011 at 3:32 PM, Arun C Murthy <[EMAIL PROTECTED]>
>wrote:
>
>> Andrew,
>>
>>
>> On Nov 22, 2011, at 1:43 PM, Andrew Bayer wrote:
>>
>> > Hi all -
>> >
>> > I've been unable to find a revision in svn that actually corresponds
>> > directly to the contents of hadoop-0.23.0-src.tar.gz. The POMs in the
>> > tarball all have <version>0.23.0</version>, but the release-0.23.0
>>tag,
>> > everything on branch-0.23, everything on branch-0.23.0, everything on
>>the
>> > rc branches, etc have <version>0.23.0-SNAPSHOT</version>. Is this
>> something
>> > which could be fixed?
>> >
>>
>> It wasn't clear at that time, so I used 'mvn versions:set' to create the
>> release. I could go ahead and commit, Tom?
>>
>> I've documented that in
>> http://wiki.apache.org/hadoop/HowToReleasePostMavenization.
>>
>> > Also, shouldn't <version> on branch-0.23 now be 0.23.1-SNAPSHOT?
>>
>> That's easy to do, but, again I'm sketchy about when we change it to
>> 0.23.1 - should that be done in a branch-0.23.1?
>>
>> Arun

Or you can just tag it x.y.z-rc0, and 'svn mv' it to the final tag spot
without the rc designation if it is approved, else svn rm it.  I'm not
sure why you would need to create a branch for each release, rather than
simply a tag for each release.

svn cp branches/0.23.x tags/0.23.1-rc0
cd tags/0.23.1-rc0
mvn versions:set . . . (to 0.23.1, then commit)
svn commit  (tag created with updated poms)

vote passes ....
svn mv tags/0.23.1-rc0 tags/0.23.1

The 'tags/0.23.1-rc0' above can be replaced with any svn path you wish
that is temporary.

On 11/22/11 5:03 PM, "Arun C Murthy" <[EMAIL PROTECTED]> wrote:

>
>On Nov 22, 2011, at 4:33 PM, Tom White wrote:
>> I think 'mvn versions:set' should be called (and changes committed)
>> before creating the release candidate tag. I.e. after step 4 of
>> 'Updating Release Branch'  on that wiki page.
>
>Furthermore, we need to create a branch for the actual version e.g.
>branch-0.23.1 where we commit it. Then, branch-0.23 should have version
>set to 0.23.2-SNAPSHOT.
>
>I'll update the wiki to reflect these.
>
>Arun

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

On 11/22/2011 08:46 PM, Scott Carey wrote:
> Or you can just tag it x.y.z-rc0, and 'svn mv' it to the final tag spot
> without the rc designation if it is approved, else svn rm it.  I'm not
> sure why you would need to create a branch for each release, rather than
> simply a tag for each release.

+1

Doug

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

The confusion arises from the unfortunate conceptual conflation of
artifact reference and artifact provenance.

Maven version is technically for artifact reference. For released
artifacts, the reference has a 1-1 mapping to particular revision/tag
(provenance) in the repository. SNAPSHOT is very much misunderstood by
many, because it's a pure reference to latest artifacts in a
particular branch and meaningless for provenance purpose. If a
downstream project choose to use SNAPSHOT references, it choose to
give up the provenance property of released artifacts in favor of the
convenience of the reference.

Fortunately, artifact provenance can be comprehensively solved by
HADOOP-7368. I welcome feedback on that particular JIRA.

__Luke

On Thu, Nov 24, 2011 at 4:41 AM, Steve Loughran <[EMAIL PROTECTED]> wrote:
> 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.