Victor,
my underlying problem with the current GeoServer stable branch pom versioning convention is, why should a branch care if a tag has been created? By using (for example) 2.0.3-SNAPSHOT, developers have a completely unnecessary burden of having to update the branch whenever a release tag is made. But that is the current convention.
I checked and 2.0.3-SNAPSHOT is a valid identifier.
This proposal is how Maven now works:
http://docs.codehaus.org/display/MAVEN/Versioning
Here is the old discussion, the last time I complained about it:
------ Original Message --------
Subject: Re: [Geoserver-devel] 2.0.x SNAPSHOT version?
Date: Sat, 28 Nov 2009 03:19:38 +0800
From: Justin Deoliveira <jdeolive@anonymised.com>
To: Caradoc-Davies, Ben (E&M, Kensington) <Ben.Caradoc-Davies@anonymised.com>
CC: Geoserver-devel <geoserver-devel@lists.sourceforge.net>
I don't think we have ever been 100% consistent about this. But in
general on the stable branch we have included the patch number in
snapshot version numbers.
I know others have stated that this looks odd as well. I do find it kind
of useful to be able to tell what release stream a snapshot comes from,
but it makes it a pain for projects depending on geoserver.
Should we propose a change?
Ben Caradoc-Davies wrote:
> I just noticed that the pom gs.version on 2.0.x is set to
>
> 2.0.1-SNAPSHOT
>
> Is this intended? I though that the head of this branch would remain as
>
> 2.0-SNAPSHOT
>
> Or did I miss something?
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
Ben Caradoc-Davies ha scritto:
Victor,
my underlying problem with the current GeoServer stable branch pom versioning convention is, why should a branch care if a tag has been created? By using (for example) 2.0.3-SNAPSHOT, developers have a completely unnecessary burden of having to update the branch whenever a release tag is made. But that is the current convention.
I checked and 2.0.3-SNAPSHOT is a valid identifier.
This proposal is how Maven now works:
http://docs.codehaus.org/display/MAVEN/Versioning
Here is the old discussion, the last time I complained about it:
I'd prefer to just keep the poms in the branch unmodified as
well, using 2.0-SNAPSHOT.
One less moving part in the release process, and I fail to see the
advantage of using something like 2.0.3-SNAPSHOT.
Versioning wise it would be _great_ if the artifacts produced
by the nightly build had, right in the middle of the GUI,
a version number including the date of the build instead of
generically 2.0-SNAPSHOT. But that is a different issue.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
[Subject changed to mark it as a proposal]
On 20/05/10 14:29, Andrea Aime wrote:
I'd prefer to just keep the poms in the branch unmodified as
well, using 2.0-SNAPSHOT.
One less moving part in the release process, and I fail to see the
advantage of using something like 2.0.3-SNAPSHOT.
We are stuck on this convention for 2.0.x because 2.0.3-SNAPSHOT is a later version than 2.0-SNAPSHOT. Our next opportunity stop making work for ourselves is when we release 2.1.0 and make 2.1.x as the new stable branch.
I propose that, when 2.1.x is branched, we keep the pom version as 2.1-SNAPSHOT, and similarly for subsequent branches.
To clarify, I propose that for 2.1.x and later:
(1) Only tags should get their pom versions updated when a tag is made.
(2) The parent branch is not changed when a tag is made.
(3) Trunk pom versions are still updated when a new stable branch is made, with the new branch inheriting the old pom version (this is what we do now, so this does not change).
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre