commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject RE: Maven build fixes affecting almost all projects
Date Tue, 08 Nov 2005 13:32:49 GMT
Hi Dion,

Dion Gillard wrote on Tuesday, November 08, 2005 1:28 PM:

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

It is just error-prone. If it is the last step of the release manager, it is a defined part
of the release. Otherwise you have to hope, that everybody that does a change will also remember
to check the version. Additionally the released artifact is publiched with a hash code. Building
the artifacts by a different user will change the hash code of the artifact (since the user
name is part of the manifest) and I am not sure if this is the only element from the local
environment, that influences this value! The existance of the same artifact with multiple
hash codes is also not the best situation.

- Jörg

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

View raw message