You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Michael Hüttermann <mi...@huettermann.net> on 2009/04/22 15:44:00 UTC
RELEASE and branches
Hello experts,
how do you set up the process if you use RELEASE for a dependency in a
POM, and work with VCS branches ? What is your best practice? Probably a
branch will have to adress another, older version of an artifact, actually
it has to adress a stable, tagged version. What happens if on HEAD you use
new versions of dependencies (so a new version for RELEASE), ... do you
adjust all of your branches to remove the RELEASE token and enter a
dedicated version? Isn't that a nightmare ?
Thanks !!
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
2009/4/22 David Hoffer <dh...@gmail.com>
> Ahhh,
>
> A plugin to fix version range problems, I'll have to ckeck this out.
>
> -Dave
>
> On Wed, Apr 22, 2009 at 10:41 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> > 2009/4/22 David Hoffer <dh...@gmail.com>
> > > On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > > > Of course version ranges only work if you follow maven's rules for
> > > version
> > > > numbering... if you cannot follow maven's (some would say slightly
> > > strange)
> > > > version numbering scheme you will need to do some manual work... to
> > help
> > > > automate the manual work, you'll probably end up using
> > > > versions-maven-plugin
> > > > and specifying the version using a property.
>
Of course this was what I said in my first response ;-)
-Stephen
Re: RELEASE and branches
Posted by David Hoffer <dh...@gmail.com>.
Ahhh,
A plugin to fix version range problems, I'll have to ckeck this out.
-Dave
On Wed, Apr 22, 2009 at 10:41 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Which is where using properties and the versions-maven-plugin comes to the
> rescue....
>
> <project>
> ...
> <dependencies>
> ...
> <dependency>
> <groupId>com.foobar</groupId>
> <artifactId>foobar-core</artifactId>
> <version>${foobar-version}</version>
> </dependency>
> <dependency>
> <groupId>com.foobar</groupId>
> <artifactId>foobar-optional</artifactId>
> <version>${foobar-version}</version>
> </dependency>
> ...
> </dependencies>
> ...
> <properties>
> <foobar-version>1.2</foobar-version>
> </properties>
> ...
> <build>
> <plugins>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>versions-maven-plugin</artifactId>
> <version>1.0-alpha-3-SNAPSHOT</version>
> <configuration>
> <properties>
> <property>
> <name>foobar-version</name>
> <version>[1.2,2.0-!)</version>
> </property>
> </properties>
> </configuration>
> </plugin>
> </plugins>
> </build>
> ...
> </project>
>
> running
>
> mvn versions:update-properties
>
> will look for newer versions of both linked artifacts that are within the
> specified range and update the property if required.
>
> mvn versions:update-properties -DallowSnapshots=true
>
> is the only way to get -SNAPSHOT versions...
>
> Note: if your reactor contained a -SNAPSHOT version of both of the foobar
> dependencies, then update-properties will detect this and assume that you
> probably want to use the version from the reactor and not the previous
> release... but there's a flag to turn that behaviour off.
>
> -Stephen
>
> 2009/4/22 David Hoffer <dh...@gmail.com>
>
> > Unfortunately version ranges have so many bugs i don't find them useful
> > either. The problem with version ranges is that they will, in most
> cases,
> > include snapshots although that's both not intended and violates the
> > version
> > range spec.
> >
> > -Dave
> >
> > On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> > >
> > > > Hello experts,
> > > >
> > > > how do you set up the process if you use RELEASE for a dependency in
> a
> > > > POM, and work with VCS branches ?
> > >
> > >
> > > you stop using RELEASE for a dependency.
> > >
> > > RELEASE corresponds to the last released version... so if you release,
> in
> > > order
> > >
> > > 1.0.0
> > > 1.0.1
> > > 1.1.0
> > > 1.1.1
> > > 2.0.0
> > > 1.0.2
> > >
> > > Then RELEASE will correspond to 1.0.2 as that was the last version
> > > released.
> > >
> > > The solution is to use version ranges, i.e. work on the 1.0.x branch
> > would
> > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > > 1.0.0
> > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> > that
> > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
> less
> > > than 1.1.0)
> > >
> > > Of course version ranges only work if you follow maven's rules for
> > version
> > > numbering... if you cannot follow maven's (some would say slightly
> > strange)
> > > version numbering scheme you will need to do some manual work... to
> help
> > > automate the manual work, you'll probably end up using
> > > versions-maven-plugin
> > > and specifying the version using a property.
> > >
> > >
> > > > What is your best practice? Probably a
> > > > branch will have to adress another, older version of an artifact,
> > > actually
> > > > it has to adress a stable, tagged version. What happens if on HEAD
> you
> > > use
> > > > new versions of dependencies (so a new version for RELEASE), ... do
> you
> > > > adjust all of your branches to remove the RELEASE token and enter a
> > > > dedicated version? Isn't that a nightmare ?
> > >
> > >
> > > I think you will realise from my earlier comment that there is *no way
> in
> > > hell* that you would use RELEASE.
> > >
> > > FYI, the LATEST and RELEASE versions were initially more for use in
> > > specifying plugin versions... but they are so problematic that everyone
> > > pretty much avoids them
> > >
> > > -Stephen
> > >
> > > >
> > > >
> > > > Thanks !!
> > > >
> > > >
> > > > Michael
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
Which is where using properties and the versions-maven-plugin comes to the
rescue....
<project>
...
<dependencies>
...
<dependency>
<groupId>com.foobar</groupId>
<artifactId>foobar-core</artifactId>
<version>${foobar-version}</version>
</dependency>
<dependency>
<groupId>com.foobar</groupId>
<artifactId>foobar-optional</artifactId>
<version>${foobar-version}</version>
</dependency>
...
</dependencies>
...
<properties>
<foobar-version>1.2</foobar-version>
</properties>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>1.0-alpha-3-SNAPSHOT</version>
<configuration>
<properties>
<property>
<name>foobar-version</name>
<version>[1.2,2.0-!)</version>
</property>
</properties>
</configuration>
</plugin>
</plugins>
</build>
...
</project>
running
mvn versions:update-properties
will look for newer versions of both linked artifacts that are within the
specified range and update the property if required.
mvn versions:update-properties -DallowSnapshots=true
is the only way to get -SNAPSHOT versions...
Note: if your reactor contained a -SNAPSHOT version of both of the foobar
dependencies, then update-properties will detect this and assume that you
probably want to use the version from the reactor and not the previous
release... but there's a flag to turn that behaviour off.
-Stephen
2009/4/22 David Hoffer <dh...@gmail.com>
> Unfortunately version ranges have so many bugs i don't find them useful
> either. The problem with version ranges is that they will, in most cases,
> include snapshots although that's both not intended and violates the
> version
> range spec.
>
> -Dave
>
> On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> >
> > > Hello experts,
> > >
> > > how do you set up the process if you use RELEASE for a dependency in a
> > > POM, and work with VCS branches ?
> >
> >
> > you stop using RELEASE for a dependency.
> >
> > RELEASE corresponds to the last released version... so if you release, in
> > order
> >
> > 1.0.0
> > 1.0.1
> > 1.1.0
> > 1.1.1
> > 2.0.0
> > 1.0.2
> >
> > Then RELEASE will correspond to 1.0.2 as that was the last version
> > released.
> >
> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> would
> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > 1.0.0
> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> that
> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> > than 1.1.0)
> >
> > Of course version ranges only work if you follow maven's rules for
> version
> > numbering... if you cannot follow maven's (some would say slightly
> strange)
> > version numbering scheme you will need to do some manual work... to help
> > automate the manual work, you'll probably end up using
> > versions-maven-plugin
> > and specifying the version using a property.
> >
> >
> > > What is your best practice? Probably a
> > > branch will have to adress another, older version of an artifact,
> > actually
> > > it has to adress a stable, tagged version. What happens if on HEAD you
> > use
> > > new versions of dependencies (so a new version for RELEASE), ... do you
> > > adjust all of your branches to remove the RELEASE token and enter a
> > > dedicated version? Isn't that a nightmare ?
> >
> >
> > I think you will realise from my earlier comment that there is *no way in
> > hell* that you would use RELEASE.
> >
> > FYI, the LATEST and RELEASE versions were initially more for use in
> > specifying plugin versions... but they are so problematic that everyone
> > pretty much avoids them
> >
> > -Stephen
> >
> > >
> > >
> > > Thanks !!
> > >
> > >
> > > Michael
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: RELEASE and branches
Posted by David Hoffer <dh...@gmail.com>.
Unfortunately version ranges have so many bugs i don't find them useful
either. The problem with version ranges is that they will, in most cases,
include snapshots although that's both not intended and violates the version
range spec.
-Dave
On Wed, Apr 22, 2009 at 10:05 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>
> > Hello experts,
> >
> > how do you set up the process if you use RELEASE for a dependency in a
> > POM, and work with VCS branches ?
>
>
> you stop using RELEASE for a dependency.
>
> RELEASE corresponds to the last released version... so if you release, in
> order
>
> 1.0.0
> 1.0.1
> 1.1.0
> 1.1.1
> 2.0.0
> 1.0.2
>
> Then RELEASE will correspond to 1.0.2 as that was the last version
> released.
>
> The solution is to use version ranges, i.e. work on the 1.0.x branch would
> depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> 1.0.0
> and less than 1.1.0-! (which thanks to the joys of ascii sorting means that
> you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> than 1.1.0)
>
> Of course version ranges only work if you follow maven's rules for version
> numbering... if you cannot follow maven's (some would say slightly strange)
> version numbering scheme you will need to do some manual work... to help
> automate the manual work, you'll probably end up using
> versions-maven-plugin
> and specifying the version using a property.
>
>
> > What is your best practice? Probably a
> > branch will have to adress another, older version of an artifact,
> actually
> > it has to adress a stable, tagged version. What happens if on HEAD you
> use
> > new versions of dependencies (so a new version for RELEASE), ... do you
> > adjust all of your branches to remove the RELEASE token and enter a
> > dedicated version? Isn't that a nightmare ?
>
>
> I think you will realise from my earlier comment that there is *no way in
> hell* that you would use RELEASE.
>
> FYI, the LATEST and RELEASE versions were initially more for use in
> specifying plugin versions... but they are so problematic that everyone
> pretty much avoids them
>
> -Stephen
>
> >
> >
> > Thanks !!
> >
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
I should point out that I never use timestamp snapshots... but then we build
everything locally, and our CI server does not deploy snapshots... we had
too many issues with both random snapshot updates, and non-full builds
2009/4/22 Stephen Connolly <st...@gmail.com>
> versions:lock-snapshots
>
> and then
>
> versions:unlock-snapshots
>
> to turn them back to normal before reintegrating your branch
>
>
> 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>
>> ok, I see, thanks! There is another concept using a generic version:
>> snapshots. What do you do with your SNAPSHOTs while branching then? Do you
>> go through all your POMs and dependencies replacing the snapshot token
>> with the real snapshot version including timestamp? You can say "ok, I
>> will never use RELEASE" but you want to use the snapshot mechanism in the
>> daily work for sure I guess. What's your strategy here while branching ?
>>
>> Thanks for your time !!!
>>
>> Michael
>>
>>
>>
>> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>> >
>> >> Hello experts,
>> >>
>> >> how do you set up the process if you use RELEASE for a dependency in a
>> >> POM, and work with VCS branches ?
>> >
>> >
>> > you stop using RELEASE for a dependency.
>> >
>> > RELEASE corresponds to the last released version... so if you release,
>> in
>> > order
>> >
>> > 1.0.0
>> > 1.0.1
>> > 1.1.0
>> > 1.1.1
>> > 2.0.0
>> > 1.0.2
>> >
>> > Then RELEASE will correspond to 1.0.2 as that was the last version
>> > released.
>> >
>> > The solution is to use version ranges, i.e. work on the 1.0.x branch
>> would
>> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
>> > 1.0.0
>> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
>> > that
>> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
>> less
>> > than 1.1.0)
>> >
>> > Of course version ranges only work if you follow maven's rules for
>> version
>> > numbering... if you cannot follow maven's (some would say slightly
>> > strange)
>> > version numbering scheme you will need to do some manual work... to help
>> > automate the manual work, you'll probably end up using
>> > versions-maven-plugin
>> > and specifying the version using a property.
>> >
>> >
>> >> What is your best practice? Probably a
>> >> branch will have to adress another, older version of an artifact,
>> >> actually
>> >> it has to adress a stable, tagged version. What happens if on HEAD you
>> >> use
>> >> new versions of dependencies (so a new version for RELEASE), ... do you
>> >> adjust all of your branches to remove the RELEASE token and enter a
>> >> dedicated version? Isn't that a nightmare ?
>> >
>> >
>> > I think you will realise from my earlier comment that there is *no way
>> in
>> > hell* that you would use RELEASE.
>> >
>> > FYI, the LATEST and RELEASE versions were initially more for use in
>> > specifying plugin versions... but they are so problematic that everyone
>> > pretty much avoids them
>> >
>> > -Stephen
>> >
>> >>
>> >>
>> >> Thanks !!
>> >>
>> >>
>> >> Michael
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
versions:lock-snapshots
and then
versions:unlock-snapshots
to turn them back to normal before reintegrating your branch
2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> ok, I see, thanks! There is another concept using a generic version:
> snapshots. What do you do with your SNAPSHOTs while branching then? Do you
> go through all your POMs and dependencies replacing the snapshot token
> with the real snapshot version including timestamp? You can say "ok, I
> will never use RELEASE" but you want to use the snapshot mechanism in the
> daily work for sure I guess. What's your strategy here while branching ?
>
> Thanks for your time !!!
>
> Michael
>
>
>
> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> >
> >> Hello experts,
> >>
> >> how do you set up the process if you use RELEASE for a dependency in a
> >> POM, and work with VCS branches ?
> >
> >
> > you stop using RELEASE for a dependency.
> >
> > RELEASE corresponds to the last released version... so if you release, in
> > order
> >
> > 1.0.0
> > 1.0.1
> > 1.1.0
> > 1.1.1
> > 2.0.0
> > 1.0.2
> >
> > Then RELEASE will correspond to 1.0.2 as that was the last version
> > released.
> >
> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> would
> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > 1.0.0
> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> > that
> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> > than 1.1.0)
> >
> > Of course version ranges only work if you follow maven's rules for
> version
> > numbering... if you cannot follow maven's (some would say slightly
> > strange)
> > version numbering scheme you will need to do some manual work... to help
> > automate the manual work, you'll probably end up using
> > versions-maven-plugin
> > and specifying the version using a property.
> >
> >
> >> What is your best practice? Probably a
> >> branch will have to adress another, older version of an artifact,
> >> actually
> >> it has to adress a stable, tagged version. What happens if on HEAD you
> >> use
> >> new versions of dependencies (so a new version for RELEASE), ... do you
> >> adjust all of your branches to remove the RELEASE token and enter a
> >> dedicated version? Isn't that a nightmare ?
> >
> >
> > I think you will realise from my earlier comment that there is *no way in
> > hell* that you would use RELEASE.
> >
> > FYI, the LATEST and RELEASE versions were initially more for use in
> > specifying plugin versions... but they are so problematic that everyone
> > pretty much avoids them
> >
> > -Stephen
> >
> >>
> >>
> >> Thanks !!
> >>
> >>
> >> Michael
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
It depends...
if your build is reliable and never fails... if all your components always
have the same version number... if all your modules are in the same tree...
then yes the the release plugin will sort it out for you.
however, if you have a long flakey build (we have one that is about 4 hours
and fails during release if you look at it sideways)
what we do with that build is release the reliable bits first, and then the
unreliable modules separately... this can (and does) result in different
build numbers for each module, but that's ok.
-Stephen
2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> starting at lowest dependencies and work the way ... having a pretty big
> build system this sounds like a nightmare. Just only using the maven
> release plugin on the top level isn't enough right ?!
>
> Michael
>
>
Re: RELEASE and branches
Posted by David Hoffer <dh...@gmail.com>.
Yes, just updating the pom to remove the manual parts is a great step
forward.
-Dave
On Wed, Apr 22, 2009 at 11:35 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 2009/4/22 David Hoffer <dh...@gmail.com>
>
> > Sorry, I might not be clear on the big problem you are trying to solve.
> > The
> > release plugin works for us. Its used for each dependency you need to
> > release. We try to limit snapshot usage overall, that's just for things
> a
> > project is actively changing, else use a released version.
> >
> > The 'biggest' problem, I have had, is not being able to use version
> > ranges...means I have to modify the dependency version in the consuming
> > projects, but never more than one per per dependency so its manageable.
> > Now
> > I see there is the versions-maven-plugin so potentially this will allow
> > version ranges which will eliminate this manual process.
> >
> > -Dave
> >
> >
> FYI, the versions-maven-plugin *modifies* your pom.xml... so you will still
> have to commit the changed poms to SCM... but you don't have to change them
> by hand any more... the process should go something like this
>
> mvn versions:update-properties
> mvn clean verify
> if that worked
> mvn versions:commit
> svn ci -m "updated the versions"
> else
> mvn versions:revert
> fi
>
> Note: versions-maven-plugin (from 1.0-alpha-3) uses a "poor man's" scm to
> allow you to roll back the changes it made quickly
>
> -Stephen
>
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
2009/4/22 David Hoffer <dh...@gmail.com>
> Sorry, I might not be clear on the big problem you are trying to solve.
> The
> release plugin works for us. Its used for each dependency you need to
> release. We try to limit snapshot usage overall, that's just for things a
> project is actively changing, else use a released version.
>
> The 'biggest' problem, I have had, is not being able to use version
> ranges...means I have to modify the dependency version in the consuming
> projects, but never more than one per per dependency so its manageable.
> Now
> I see there is the versions-maven-plugin so potentially this will allow
> version ranges which will eliminate this manual process.
>
> -Dave
>
>
FYI, the versions-maven-plugin *modifies* your pom.xml... so you will still
have to commit the changed poms to SCM... but you don't have to change them
by hand any more... the process should go something like this
mvn versions:update-properties
mvn clean verify
if that worked
mvn versions:commit
svn ci -m "updated the versions"
else
mvn versions:revert
fi
Note: versions-maven-plugin (from 1.0-alpha-3) uses a "poor man's" scm to
allow you to roll back the changes it made quickly
-Stephen
Re: RELEASE and branches
Posted by David Hoffer <dh...@gmail.com>.
Sorry, I might not be clear on the big problem you are trying to solve. The
release plugin works for us. Its used for each dependency you need to
release. We try to limit snapshot usage overall, that's just for things a
project is actively changing, else use a released version.
The 'biggest' problem, I have had, is not being able to use version
ranges...means I have to modify the dependency version in the consuming
projects, but never more than one per per dependency so its manageable. Now
I see there is the versions-maven-plugin so potentially this will allow
version ranges which will eliminate this manual process.
-Dave
On Wed, Apr 22, 2009 at 11:17 AM, Michael Hüttermann <
michael@huettermann.net> wrote:
> starting at lowest dependencies and work the way ... having a pretty big
> build system this sounds like a nightmare. Just only using the maven
> release plugin on the top level isn't enough right ?!
>
> Michael
>
>
>
> > We use snapshot for all versions while developing then when release time
> > comes we release (maven release plugin) each project, starting at the
> > lowest
> > dependency and work our way up to the top. The release plugin will
> > automatically update each project to the next snapshot version, as well
> as
> > SCM tagging, etc.
> >
> >
> > On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann <
> > michael@huettermann.net> wrote:
> >
> >> ok, I see, thanks! There is another concept using a generic version:
> >> snapshots. What do you do with your SNAPSHOTs while branching then? Do
> >> you
> >> go through all your POMs and dependencies replacing the snapshot token
> >> with the real snapshot version including timestamp? You can say "ok, I
> >> will never use RELEASE" but you want to use the snapshot mechanism in
> >> the
> >> daily work for sure I guess. What's your strategy here while branching ?
> >>
> >> Thanks for your time !!!
> >>
> >> Michael
> >>
> >>
> >>
> >> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> >> >
> >> >> Hello experts,
> >> >>
> >> >> how do you set up the process if you use RELEASE for a dependency in
> >> a
> >> >> POM, and work with VCS branches ?
> >> >
> >> >
> >> > you stop using RELEASE for a dependency.
> >> >
> >> > RELEASE corresponds to the last released version... so if you release,
> >> in
> >> > order
> >> >
> >> > 1.0.0
> >> > 1.0.1
> >> > 1.1.0
> >> > 1.1.1
> >> > 2.0.0
> >> > 1.0.2
> >> >
> >> > Then RELEASE will correspond to 1.0.2 as that was the last version
> >> > released.
> >> >
> >> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> >> would
> >> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> >> > 1.0.0
> >> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> >> > that
> >> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
> >> less
> >> > than 1.1.0)
> >> >
> >> > Of course version ranges only work if you follow maven's rules for
> >> version
> >> > numbering... if you cannot follow maven's (some would say slightly
> >> > strange)
> >> > version numbering scheme you will need to do some manual work... to
> >> help
> >> > automate the manual work, you'll probably end up using
> >> > versions-maven-plugin
> >> > and specifying the version using a property.
> >> >
> >> >
> >> >> What is your best practice? Probably a
> >> >> branch will have to adress another, older version of an artifact,
> >> >> actually
> >> >> it has to adress a stable, tagged version. What happens if on HEAD
> >> you
> >> >> use
> >> >> new versions of dependencies (so a new version for RELEASE), ... do
> >> you
> >> >> adjust all of your branches to remove the RELEASE token and enter a
> >> >> dedicated version? Isn't that a nightmare ?
> >> >
> >> >
> >> > I think you will realise from my earlier comment that there is *no way
> >> in
> >> > hell* that you would use RELEASE.
> >> >
> >> > FYI, the LATEST and RELEASE versions were initially more for use in
> >> > specifying plugin versions... but they are so problematic that
> >> everyone
> >> > pretty much avoids them
> >> >
> >> > -Stephen
> >> >
> >> >>
> >> >>
> >> >> Thanks !!
> >> >>
> >> >>
> >> >> Michael
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: RELEASE and branches
Posted by Michael Hüttermann <mi...@huettermann.net>.
starting at lowest dependencies and work the way ... having a pretty big
build system this sounds like a nightmare. Just only using the maven
release plugin on the top level isn't enough right ?!
Michael
> We use snapshot for all versions while developing then when release time
> comes we release (maven release plugin) each project, starting at the
> lowest
> dependency and work our way up to the top. The release plugin will
> automatically update each project to the next snapshot version, as well as
> SCM tagging, etc.
>
>
> On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann <
> michael@huettermann.net> wrote:
>
>> ok, I see, thanks! There is another concept using a generic version:
>> snapshots. What do you do with your SNAPSHOTs while branching then? Do
>> you
>> go through all your POMs and dependencies replacing the snapshot token
>> with the real snapshot version including timestamp? You can say "ok, I
>> will never use RELEASE" but you want to use the snapshot mechanism in
>> the
>> daily work for sure I guess. What's your strategy here while branching ?
>>
>> Thanks for your time !!!
>>
>> Michael
>>
>>
>>
>> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>> >
>> >> Hello experts,
>> >>
>> >> how do you set up the process if you use RELEASE for a dependency in
>> a
>> >> POM, and work with VCS branches ?
>> >
>> >
>> > you stop using RELEASE for a dependency.
>> >
>> > RELEASE corresponds to the last released version... so if you release,
>> in
>> > order
>> >
>> > 1.0.0
>> > 1.0.1
>> > 1.1.0
>> > 1.1.1
>> > 2.0.0
>> > 1.0.2
>> >
>> > Then RELEASE will correspond to 1.0.2 as that was the last version
>> > released.
>> >
>> > The solution is to use version ranges, i.e. work on the 1.0.x branch
>> would
>> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
>> > 1.0.0
>> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
>> > that
>> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
>> less
>> > than 1.1.0)
>> >
>> > Of course version ranges only work if you follow maven's rules for
>> version
>> > numbering... if you cannot follow maven's (some would say slightly
>> > strange)
>> > version numbering scheme you will need to do some manual work... to
>> help
>> > automate the manual work, you'll probably end up using
>> > versions-maven-plugin
>> > and specifying the version using a property.
>> >
>> >
>> >> What is your best practice? Probably a
>> >> branch will have to adress another, older version of an artifact,
>> >> actually
>> >> it has to adress a stable, tagged version. What happens if on HEAD
>> you
>> >> use
>> >> new versions of dependencies (so a new version for RELEASE), ... do
>> you
>> >> adjust all of your branches to remove the RELEASE token and enter a
>> >> dedicated version? Isn't that a nightmare ?
>> >
>> >
>> > I think you will realise from my earlier comment that there is *no way
>> in
>> > hell* that you would use RELEASE.
>> >
>> > FYI, the LATEST and RELEASE versions were initially more for use in
>> > specifying plugin versions... but they are so problematic that
>> everyone
>> > pretty much avoids them
>> >
>> > -Stephen
>> >
>> >>
>> >>
>> >> Thanks !!
>> >>
>> >>
>> >> Michael
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
I guess we need to separate 3rd party dependencies and internal
dependencies.
In general you do not want to depend on a -SNAPSHOT version of a third party
dependency...
for example in between releases, there is no way I'd switch from
log4j-1.2.15 to log4j-1.2.16-SNAPSHOT ___unless___ there was a bug in 1.2.15
that was affecting my code, in which case I might switch to the -SNAPSHOT
until either log4j releases, or I need to release at which point I would
also do a release of log4j-1.2.16-mycompany-01
However, if these are internal dependencies, chances are that you actually
do want the -SNAPSHOT dependency...
so if i'm working on foobar-optional 2.3-SNAPSHOT I will depend on
foobar-core 2.3-SNAPSHOT also...
now there's this quirky feature that I'm adding to foobar-optional, and the
guys working on foobar-core are great at breaking their build... so what I
do in that case is I lock my -SNAPSHOT dependency on foobar-core to
2.3-20090422.181944-5 because that one is working, then I add my feature and
when I'm finished I restore back to a regular -SNAPSHOT and start worrying
about integrating with the changes that they made to foobar-core
-Stephen
2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> hmm how does that help between releases? You need to adress stable,
> labeled versions of artifacts .. so in my feeling you aren't allowed to
> use any snapshot version at all .. ?
>
> Michael
>
>
> > I think (actually I hope) he's talking about between releases.
> >
> > trunk might be moving rapidly, so you fork a branch to work on a
> > feature...
> > you don't want the changes to the artifacts from trunk screwing with your
> > build until you are ready to merge the branch back to trunk...
> >
> > If he's got some other plan then I'd advise him against using timestamp
> > snapshots for such a crazy plan (which I'm sure he will share in an
> effort
> > to prove that it's not crazy)
> >
> > -Stephen
>
>
Re: RELEASE and branches
Posted by Michael Hüttermann <mi...@huettermann.net>.
hmm how does that help between releases? You need to adress stable,
labeled versions of artifacts .. so in my feeling you aren't allowed to
use any snapshot version at all .. ?
Michael
> I think (actually I hope) he's talking about between releases.
>
> trunk might be moving rapidly, so you fork a branch to work on a
> feature...
> you don't want the changes to the artifacts from trunk screwing with your
> build until you are ready to merge the branch back to trunk...
>
> If he's got some other plan then I'd advise him against using timestamp
> snapshots for such a crazy plan (which I'm sure he will share in an effort
> to prove that it's not crazy)
>
> -Stephen
>
> 2009/4/22 David Hoffer <dh...@gmail.com>
>
>> We use snapshot for all versions while developing then when release time
>> comes we release (maven release plugin) each project, starting at the
>> lowest
>> dependency and work our way up to the top. The release plugin will
>> automatically update each project to the next snapshot version, as well
>> as
>> SCM tagging, etc.
>>
>>
>> On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann <
>> michael@huettermann.net> wrote:
>>
>> > ok, I see, thanks! There is another concept using a generic version:
>> > snapshots. What do you do with your SNAPSHOTs while branching then? Do
>> you
>> > go through all your POMs and dependencies replacing the snapshot token
>> > with the real snapshot version including timestamp? You can say "ok, I
>> > will never use RELEASE" but you want to use the snapshot mechanism in
>> the
>> > daily work for sure I guess. What's your strategy here while branching
>> ?
>> >
>> > Thanks for your time !!!
>> >
>> > Michael
>> >
>> >
>> >
>> > > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>> > >
>> > >> Hello experts,
>> > >>
>> > >> how do you set up the process if you use RELEASE for a dependency
>> in a
>> > >> POM, and work with VCS branches ?
>> > >
>> > >
>> > > you stop using RELEASE for a dependency.
>> > >
>> > > RELEASE corresponds to the last released version... so if you
>> release,
>> in
>> > > order
>> > >
>> > > 1.0.0
>> > > 1.0.1
>> > > 1.1.0
>> > > 1.1.1
>> > > 2.0.0
>> > > 1.0.2
>> > >
>> > > Then RELEASE will correspond to 1.0.2 as that was the last version
>> > > released.
>> > >
>> > > The solution is to use version ranges, i.e. work on the 1.0.x branch
>> > would
>> > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal
>> to
>> > > 1.0.0
>> > > and less than 1.1.0-! (which thanks to the joys of ascii sorting
>> means
>> > > that
>> > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
>> less
>> > > than 1.1.0)
>> > >
>> > > Of course version ranges only work if you follow maven's rules for
>> > version
>> > > numbering... if you cannot follow maven's (some would say slightly
>> > > strange)
>> > > version numbering scheme you will need to do some manual work... to
>> help
>> > > automate the manual work, you'll probably end up using
>> > > versions-maven-plugin
>> > > and specifying the version using a property.
>> > >
>> > >
>> > >> What is your best practice? Probably a
>> > >> branch will have to adress another, older version of an artifact,
>> > >> actually
>> > >> it has to adress a stable, tagged version. What happens if on HEAD
>> you
>> > >> use
>> > >> new versions of dependencies (so a new version for RELEASE), ... do
>> you
>> > >> adjust all of your branches to remove the RELEASE token and enter a
>> > >> dedicated version? Isn't that a nightmare ?
>> > >
>> > >
>> > > I think you will realise from my earlier comment that there is *no
>> way
>> in
>> > > hell* that you would use RELEASE.
>> > >
>> > > FYI, the LATEST and RELEASE versions were initially more for use in
>> > > specifying plugin versions... but they are so problematic that
>> everyone
>> > > pretty much avoids them
>> > >
>> > > -Stephen
>> > >
>> > >>
>> > >>
>> > >> Thanks !!
>> > >>
>> > >>
>> > >> Michael
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > >> For additional commands, e-mail: users-help@maven.apache.org
>> > >>
>> > >>
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
I think (actually I hope) he's talking about between releases.
trunk might be moving rapidly, so you fork a branch to work on a feature...
you don't want the changes to the artifacts from trunk screwing with your
build until you are ready to merge the branch back to trunk...
If he's got some other plan then I'd advise him against using timestamp
snapshots for such a crazy plan (which I'm sure he will share in an effort
to prove that it's not crazy)
-Stephen
2009/4/22 David Hoffer <dh...@gmail.com>
> We use snapshot for all versions while developing then when release time
> comes we release (maven release plugin) each project, starting at the
> lowest
> dependency and work our way up to the top. The release plugin will
> automatically update each project to the next snapshot version, as well as
> SCM tagging, etc.
>
>
> On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann <
> michael@huettermann.net> wrote:
>
> > ok, I see, thanks! There is another concept using a generic version:
> > snapshots. What do you do with your SNAPSHOTs while branching then? Do
> you
> > go through all your POMs and dependencies replacing the snapshot token
> > with the real snapshot version including timestamp? You can say "ok, I
> > will never use RELEASE" but you want to use the snapshot mechanism in the
> > daily work for sure I guess. What's your strategy here while branching ?
> >
> > Thanks for your time !!!
> >
> > Michael
> >
> >
> >
> > > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> > >
> > >> Hello experts,
> > >>
> > >> how do you set up the process if you use RELEASE for a dependency in a
> > >> POM, and work with VCS branches ?
> > >
> > >
> > > you stop using RELEASE for a dependency.
> > >
> > > RELEASE corresponds to the last released version... so if you release,
> in
> > > order
> > >
> > > 1.0.0
> > > 1.0.1
> > > 1.1.0
> > > 1.1.1
> > > 2.0.0
> > > 1.0.2
> > >
> > > Then RELEASE will correspond to 1.0.2 as that was the last version
> > > released.
> > >
> > > The solution is to use version ranges, i.e. work on the 1.0.x branch
> > would
> > > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > > 1.0.0
> > > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> > > that
> > > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is
> less
> > > than 1.1.0)
> > >
> > > Of course version ranges only work if you follow maven's rules for
> > version
> > > numbering... if you cannot follow maven's (some would say slightly
> > > strange)
> > > version numbering scheme you will need to do some manual work... to
> help
> > > automate the manual work, you'll probably end up using
> > > versions-maven-plugin
> > > and specifying the version using a property.
> > >
> > >
> > >> What is your best practice? Probably a
> > >> branch will have to adress another, older version of an artifact,
> > >> actually
> > >> it has to adress a stable, tagged version. What happens if on HEAD you
> > >> use
> > >> new versions of dependencies (so a new version for RELEASE), ... do
> you
> > >> adjust all of your branches to remove the RELEASE token and enter a
> > >> dedicated version? Isn't that a nightmare ?
> > >
> > >
> > > I think you will realise from my earlier comment that there is *no way
> in
> > > hell* that you would use RELEASE.
> > >
> > > FYI, the LATEST and RELEASE versions were initially more for use in
> > > specifying plugin versions... but they are so problematic that everyone
> > > pretty much avoids them
> > >
> > > -Stephen
> > >
> > >>
> > >>
> > >> Thanks !!
> > >>
> > >>
> > >> Michael
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: RELEASE and branches
Posted by David Hoffer <dh...@gmail.com>.
We use snapshot for all versions while developing then when release time
comes we release (maven release plugin) each project, starting at the lowest
dependency and work our way up to the top. The release plugin will
automatically update each project to the next snapshot version, as well as
SCM tagging, etc.
On Wed, Apr 22, 2009 at 10:37 AM, Michael Hüttermann <
michael@huettermann.net> wrote:
> ok, I see, thanks! There is another concept using a generic version:
> snapshots. What do you do with your SNAPSHOTs while branching then? Do you
> go through all your POMs and dependencies replacing the snapshot token
> with the real snapshot version including timestamp? You can say "ok, I
> will never use RELEASE" but you want to use the snapshot mechanism in the
> daily work for sure I guess. What's your strategy here while branching ?
>
> Thanks for your time !!!
>
> Michael
>
>
>
> > 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> >
> >> Hello experts,
> >>
> >> how do you set up the process if you use RELEASE for a dependency in a
> >> POM, and work with VCS branches ?
> >
> >
> > you stop using RELEASE for a dependency.
> >
> > RELEASE corresponds to the last released version... so if you release, in
> > order
> >
> > 1.0.0
> > 1.0.1
> > 1.1.0
> > 1.1.1
> > 2.0.0
> > 1.0.2
> >
> > Then RELEASE will correspond to 1.0.2 as that was the last version
> > released.
> >
> > The solution is to use version ranges, i.e. work on the 1.0.x branch
> would
> > depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> > 1.0.0
> > and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> > that
> > you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> > than 1.1.0)
> >
> > Of course version ranges only work if you follow maven's rules for
> version
> > numbering... if you cannot follow maven's (some would say slightly
> > strange)
> > version numbering scheme you will need to do some manual work... to help
> > automate the manual work, you'll probably end up using
> > versions-maven-plugin
> > and specifying the version using a property.
> >
> >
> >> What is your best practice? Probably a
> >> branch will have to adress another, older version of an artifact,
> >> actually
> >> it has to adress a stable, tagged version. What happens if on HEAD you
> >> use
> >> new versions of dependencies (so a new version for RELEASE), ... do you
> >> adjust all of your branches to remove the RELEASE token and enter a
> >> dedicated version? Isn't that a nightmare ?
> >
> >
> > I think you will realise from my earlier comment that there is *no way in
> > hell* that you would use RELEASE.
> >
> > FYI, the LATEST and RELEASE versions were initially more for use in
> > specifying plugin versions... but they are so problematic that everyone
> > pretty much avoids them
> >
> > -Stephen
> >
> >>
> >>
> >> Thanks !!
> >>
> >>
> >> Michael
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: RELEASE and branches
Posted by Michael Hüttermann <mi...@huettermann.net>.
ok, I see, thanks! There is another concept using a generic version:
snapshots. What do you do with your SNAPSHOTs while branching then? Do you
go through all your POMs and dependencies replacing the snapshot token
with the real snapshot version including timestamp? You can say "ok, I
will never use RELEASE" but you want to use the snapshot mechanism in the
daily work for sure I guess. What's your strategy here while branching ?
Thanks for your time !!!
Michael
> 2009/4/22 Michael Hüttermann <mi...@huettermann.net>
>
>> Hello experts,
>>
>> how do you set up the process if you use RELEASE for a dependency in a
>> POM, and work with VCS branches ?
>
>
> you stop using RELEASE for a dependency.
>
> RELEASE corresponds to the last released version... so if you release, in
> order
>
> 1.0.0
> 1.0.1
> 1.1.0
> 1.1.1
> 2.0.0
> 1.0.2
>
> Then RELEASE will correspond to 1.0.2 as that was the last version
> released.
>
> The solution is to use version ranges, i.e. work on the 1.0.x branch would
> depend on [1.0.0,1.1.0-!) that is any version greater than or equal to
> 1.0.0
> and less than 1.1.0-! (which thanks to the joys of ascii sorting means
> that
> you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
> than 1.1.0)
>
> Of course version ranges only work if you follow maven's rules for version
> numbering... if you cannot follow maven's (some would say slightly
> strange)
> version numbering scheme you will need to do some manual work... to help
> automate the manual work, you'll probably end up using
> versions-maven-plugin
> and specifying the version using a property.
>
>
>> What is your best practice? Probably a
>> branch will have to adress another, older version of an artifact,
>> actually
>> it has to adress a stable, tagged version. What happens if on HEAD you
>> use
>> new versions of dependencies (so a new version for RELEASE), ... do you
>> adjust all of your branches to remove the RELEASE token and enter a
>> dedicated version? Isn't that a nightmare ?
>
>
> I think you will realise from my earlier comment that there is *no way in
> hell* that you would use RELEASE.
>
> FYI, the LATEST and RELEASE versions were initially more for use in
> specifying plugin versions... but they are so problematic that everyone
> pretty much avoids them
>
> -Stephen
>
>>
>>
>> Thanks !!
>>
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: RELEASE and branches
Posted by Stephen Connolly <st...@gmail.com>.
2009/4/22 Michael Hüttermann <mi...@huettermann.net>
> Hello experts,
>
> how do you set up the process if you use RELEASE for a dependency in a
> POM, and work with VCS branches ?
you stop using RELEASE for a dependency.
RELEASE corresponds to the last released version... so if you release, in
order
1.0.0
1.0.1
1.1.0
1.1.1
2.0.0
1.0.2
Then RELEASE will correspond to 1.0.2 as that was the last version released.
The solution is to use version ranges, i.e. work on the 1.0.x branch would
depend on [1.0.0,1.1.0-!) that is any version greater than or equal to 1.0.0
and less than 1.1.0-! (which thanks to the joys of ascii sorting means that
you will exclude any 1.1.0 version including 1.1.0-SNAPSHOT which is less
than 1.1.0)
Of course version ranges only work if you follow maven's rules for version
numbering... if you cannot follow maven's (some would say slightly strange)
version numbering scheme you will need to do some manual work... to help
automate the manual work, you'll probably end up using versions-maven-plugin
and specifying the version using a property.
> What is your best practice? Probably a
> branch will have to adress another, older version of an artifact, actually
> it has to adress a stable, tagged version. What happens if on HEAD you use
> new versions of dependencies (so a new version for RELEASE), ... do you
> adjust all of your branches to remove the RELEASE token and enter a
> dedicated version? Isn't that a nightmare ?
I think you will realise from my earlier comment that there is *no way in
hell* that you would use RELEASE.
FYI, the LATEST and RELEASE versions were initially more for use in
specifying plugin versions... but they are so problematic that everyone
pretty much avoids them
-Stephen
>
>
> Thanks !!
>
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>