commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: Maven build fixes affecting almost all projects
Date Tue, 08 Nov 2005 13:32:16 GMT
On 11/8/05, Dion Gillard <> wrote:
> On 11/8/05, Jörg Schaible <> wrote:
> > Dion Gillard wrote on Tuesday, November 08, 2005 12:11 PM:
> >
> > > Questions:
> >
> > As a general answer to the <increasedVersion>-SNAPSHOT: A POM with a final
version should never be available as latest trunk revision. Such a version may only be in
the POM when the release is cut and later immediately returned to a snapshot version. Why?
Everyone that checks out the sources, builds and installs the artifacts will overwrite the
official version from the remote repositories. Even worse if one deploys and has the right
to deploy. In the first case only the user with the wrong version in his local repository
is affected in the second one the whole community ... remember commons-io-1.0 case.
> What if the source hasn't changed from the release? This is the case
> for at least one of the changes. I'd rather the POM in trunk reflect
> what the code is. If the code changes, bump the POM. Is that such a
> hard thing to do?
The problem with that approach is that people may forget to do it,
resulting in the problems that Jorg describes.  That's why in, in the
"Post-release update" section , we say to update build the version
number. If people want to build the release version, IMHO they should
grab the release sources or checkout the tag.   We do need to agree on
the -SNAPSHOT suffice in place of -dev though, which is what most
commons components use now.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message