You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Hayes, Peter" <Pe...@fmr.com> on 2009/04/06 17:57:33 UTC
LATEST and RELEASE release version management
We use Maven in an enterprise environment and internally we are required
to execute "release" builds whenever we want to install to our testing
environment. We have found that executing many release builds can be
tedious when we have in-development snapshot dependencies that also have
to be released. We don't mind doing the releases, but the manual
version update -- release -- revert version cycle is a chore.
I was hoping that Maven could simplify this by allowing a project to
declare a dependency on LATEST or 1.0-LATEST and have the maven release
plugin resolve this to the actual latest released version available in
the repository. The subsequent fully resolved pom would then be
uploaded to the internal repository and the pom left in source control
still references LATEST.
Does maven already support something like this or would others find this
useful?
Peter Hayes
Architecture & Shared Technology Services | Fidelity Investments
Management Technology
Re: LATEST and RELEASE release version management
Posted by Tim <ch...@gmail.com>.
It does but that actually includes all SNAPSHOT versions. If you aren't
interested in snapshot versions as well that that will break.
On Wed, Apr 8, 2009 at 2:16 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> sounds like you want version ranges
>
> [1.0,2.0-!)
>
> Sent from my [rhymes with myPod] ;-)
>
>
> On 8 Apr 2009, at 01:39, Tim <ch...@gmail.com> wrote:
>
> http://jira.codehaus.org/browse/MNG-4089
>> I need to read over the bug that was linked as a duplicate more closely
>> but
>> I don't think it's the same thing.
>> What I asked for was the same as what you said with 1.0-LATEST.
>> Doing something like that or 1.0-RELEASE would actually be very beneficial
>> to people that know that minor releases won't break backwards
>> compatibility
>> but will allow for more features without having to keep changing versions.
>>
>> On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox <brianf@reply.infinity.nu
>> >wrote:
>>
>> Having the release plugin translate these values at release time
>>> _before_ the validation build and tag is the only sane way to use them.
>>> I currently have never use them because they aren't repeatable.
>>>
>>>
>>>
>>> From: Hayes, Peter [mailto:Peter.Hayes@fmr.com]
>>> Sent: Monday, April 06, 2009 12:12 PM
>>> To: Maven Users List
>>> Subject: RE: LATEST and RELEASE release version management
>>>
>>>
>>>
>>> Graham Leggett wrote:
>>>
>>> Having said that, it makes no sense to have the release plugin care
>>>> about LATEST, because by definition, building against LATEST isn't
>>>> repeatable, and in order for there to be a release, you need the build
>>>> to be repeatable.
>>>>
>>>
>>> I think this does impact the release plugin as it could offer the
>>> ability to resolve the LATEST version at release time. These builds
>>> would be reproducible because the release plugin tags the poms during
>>> the release process.
>>>
>>> I think what you're saying is that the build prior to the release build
>>> is not guaranteed to have the same dependent artifacts as the release
>>> build. I care about the release build being reproducible.
>>>
>>> Pete
>>>
>>>
>>>
>>
>> --
>>
>> Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html
>> >
>> - "A computer once beat me at chess, but it was no match for me at
>> kick
>> boxing."
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Fred Allen <http://www.brainyquote.com/quotes/authors/f/fred_allen.html> -
"Washington is no place for a good actor. The competition from bad actors is
too great."
RE: LATEST and RELEASE release version management
Posted by "Hayes, Peter" <Pe...@fmr.com>.
Version ranges seem to totally break reproducibility of released builds.
Personally, I'd like to see these eliminated from Maven altogether and
replaced with a separate version compatibility field that indicates
which versions of a dependency you are compatible with but still have a
specific version that you declare:
...
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>2.5.5</version>
<compatibility>[2.5,3.0-!)</compatibility>
</dependency>
...
This would ensure reproducibility while providing higher value version
information that could then be used within metadata and leveraged by
containers such as OSGI.
Pete
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Wednesday, April 08, 2009 3:16 AM
To: Maven Users List
Cc: Maven Users List
Subject: Re: LATEST and RELEASE release version management
sounds like you want version ranges
[1.0,2.0-!)
Sent from my [rhymes with myPod] ;-)
On 8 Apr 2009, at 01:39, Tim <ch...@gmail.com> wrote:
> http://jira.codehaus.org/browse/MNG-4089
> I need to read over the bug that was linked as a duplicate more
> closely but
> I don't think it's the same thing.
> What I asked for was the same as what you said with 1.0-LATEST.
> Doing something like that or 1.0-RELEASE would actually be very
> beneficial
> to people that know that minor releases won't break backwards
> compatibility
> but will allow for more features without having to keep changing
> versions.
>
> On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox
> <br...@reply.infinity.nu>wrote:
>
>> Having the release plugin translate these values at release time
>> _before_ the validation build and tag is the only sane way to use
>> them.
>> I currently have never use them because they aren't repeatable.
>>
>>
>>
>> From: Hayes, Peter [mailto:Peter.Hayes@fmr.com]
>> Sent: Monday, April 06, 2009 12:12 PM
>> To: Maven Users List
>> Subject: RE: LATEST and RELEASE release version management
>>
>>
>>
>> Graham Leggett wrote:
>>
>>> Having said that, it makes no sense to have the release plugin care
>>> about LATEST, because by definition, building against LATEST isn't
>>> repeatable, and in order for there to be a release, you need the
>>> build
>>> to be repeatable.
>>
>> I think this does impact the release plugin as it could offer the
>> ability to resolve the LATEST version at release time. These builds
>> would be reproducible because the release plugin tags the poms during
>> the release process.
>>
>> I think what you're saying is that the build prior to the release
>> build
>> is not guaranteed to have the same dependent artifacts as the release
>> build. I care about the release build being reproducible.
>>
>> Pete
>>
>>
>
>
> --
>
> Emo Philips
<http://www.brainyquote.com/quotes/authors/e/emo_philips.html
> >
> - "A computer once beat me at chess, but it was no match for me at
> kick
> boxing."
---------------------------------------------------------------------
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: LATEST and RELEASE release version management
Posted by Stephen Connolly <st...@gmail.com>.
sounds like you want version ranges
[1.0,2.0-!)
Sent from my [rhymes with myPod] ;-)
On 8 Apr 2009, at 01:39, Tim <ch...@gmail.com> wrote:
> http://jira.codehaus.org/browse/MNG-4089
> I need to read over the bug that was linked as a duplicate more
> closely but
> I don't think it's the same thing.
> What I asked for was the same as what you said with 1.0-LATEST.
> Doing something like that or 1.0-RELEASE would actually be very
> beneficial
> to people that know that minor releases won't break backwards
> compatibility
> but will allow for more features without having to keep changing
> versions.
>
> On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox
> <br...@reply.infinity.nu>wrote:
>
>> Having the release plugin translate these values at release time
>> _before_ the validation build and tag is the only sane way to use
>> them.
>> I currently have never use them because they aren't repeatable.
>>
>>
>>
>> From: Hayes, Peter [mailto:Peter.Hayes@fmr.com]
>> Sent: Monday, April 06, 2009 12:12 PM
>> To: Maven Users List
>> Subject: RE: LATEST and RELEASE release version management
>>
>>
>>
>> Graham Leggett wrote:
>>
>>> Having said that, it makes no sense to have the release plugin care
>>> about LATEST, because by definition, building against LATEST isn't
>>> repeatable, and in order for there to be a release, you need the
>>> build
>>> to be repeatable.
>>
>> I think this does impact the release plugin as it could offer the
>> ability to resolve the LATEST version at release time. These builds
>> would be reproducible because the release plugin tags the poms during
>> the release process.
>>
>> I think what you're saying is that the build prior to the release
>> build
>> is not guaranteed to have the same dependent artifacts as the release
>> build. I care about the release build being reproducible.
>>
>> Pete
>>
>>
>
>
> --
>
> Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html
> >
> - "A computer once beat me at chess, but it was no match for me at
> kick
> boxing."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: LATEST and RELEASE release version management
Posted by Tim <ch...@gmail.com>.
http://jira.codehaus.org/browse/MNG-4089
I need to read over the bug that was linked as a duplicate more closely but
I don't think it's the same thing.
What I asked for was the same as what you said with 1.0-LATEST.
Doing something like that or 1.0-RELEASE would actually be very beneficial
to people that know that minor releases won't break backwards compatibility
but will allow for more features without having to keep changing versions.
On Mon, Apr 6, 2009 at 6:29 PM, Brian E. Fox <br...@reply.infinity.nu>wrote:
> Having the release plugin translate these values at release time
> _before_ the validation build and tag is the only sane way to use them.
> I currently have never use them because they aren't repeatable.
>
>
>
> From: Hayes, Peter [mailto:Peter.Hayes@fmr.com]
> Sent: Monday, April 06, 2009 12:12 PM
> To: Maven Users List
> Subject: RE: LATEST and RELEASE release version management
>
>
>
> Graham Leggett wrote:
>
> >Having said that, it makes no sense to have the release plugin care
> >about LATEST, because by definition, building against LATEST isn't
> >repeatable, and in order for there to be a release, you need the build
> >to be repeatable.
>
> I think this does impact the release plugin as it could offer the
> ability to resolve the LATEST version at release time. These builds
> would be reproducible because the release plugin tags the poms during
> the release process.
>
> I think what you're saying is that the build prior to the release build
> is not guaranteed to have the same dependent artifacts as the release
> build. I care about the release build being reproducible.
>
> Pete
>
>
--
Emo Philips <http://www.brainyquote.com/quotes/authors/e/emo_philips.html>
- "A computer once beat me at chess, but it was no match for me at
kick
boxing."
RE: LATEST and RELEASE release version management
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Having the release plugin translate these values at release time
_before_ the validation build and tag is the only sane way to use them.
I currently have never use them because they aren't repeatable.
From: Hayes, Peter [mailto:Peter.Hayes@fmr.com]
Sent: Monday, April 06, 2009 12:12 PM
To: Maven Users List
Subject: RE: LATEST and RELEASE release version management
Graham Leggett wrote:
>Having said that, it makes no sense to have the release plugin care
>about LATEST, because by definition, building against LATEST isn't
>repeatable, and in order for there to be a release, you need the build
>to be repeatable.
I think this does impact the release plugin as it could offer the
ability to resolve the LATEST version at release time. These builds
would be reproducible because the release plugin tags the poms during
the release process.
I think what you're saying is that the build prior to the release build
is not guaranteed to have the same dependent artifacts as the release
build. I care about the release build being reproducible.
Pete
Re: LATEST and RELEASE release version management
Posted by Stephen Connolly <st...@gmail.com>.
If you are prepared to run maven multiple times as part of your CI build you
could achieve some of what you are looking for with the
versions-maven-plugin.
step 1. use versions-maven-plugin to update the pom to the latest releases
of all dependencies
step 2. use maven-scm-plugin to commit the modified poms back to scm
step 3. use maven-release-plugin to release the ci build
(the following 2 steps are optional)
step 4. use versions-maven-plugin to update the pom to the next snapshots of
all dependencies
step 5 . use maven-scm-plugin to commit the modified poms back to scm
ok, so you're ci build will auto-generate tags... but if you root ci
generated tags in a special ci-tags directory and only do these 3/5 step
builds nightlly it should be less of an SCM churn
-Stephen
2009/4/6 Hayes, Peter <Pe...@fmr.com>
> Graham Leggett wrote:
>
> >Having said that, it makes no sense to have the release plugin care
> >about LATEST, because by definition, building against LATEST isn't
> >repeatable, and in order for there to be a release, you need the build
> >to be repeatable.
>
> I think this does impact the release plugin as it could offer the ability
> to resolve the LATEST version at release time. These builds would be
> reproducible because the release plugin tags the poms during the release
> process.
>
> I think what you're saying is that the build prior to the release build is
> not guaranteed to have the same dependent artifacts as the release build. I
> care about the release build being reproducible.
>
> Pete
>
RE: LATEST and RELEASE release version management
Posted by "Hayes, Peter" <Pe...@fmr.com>.
Graham Leggett wrote:
>Having said that, it makes no sense to have the release plugin care
>about LATEST, because by definition, building against LATEST isn't
>repeatable, and in order for there to be a release, you need the build
>to be repeatable.
I think this does impact the release plugin as it could offer the ability to resolve the LATEST version at release time. These builds would be reproducible because the release plugin tags the poms during the release process.
I think what you're saying is that the build prior to the release build is not guaranteed to have the same dependent artifacts as the release build. I care about the release build being reproducible.
Pete
Re: LATEST and RELEASE release version management
Posted by Graham Leggett <mi...@sharp.fm>.
Hayes, Peter wrote:
> We use Maven in an enterprise environment and internally we are required
> to execute "release" builds whenever we want to install to our testing
> environment. We have found that executing many release builds can be
> tedious when we have in-development snapshot dependencies that also have
> to be released. We don't mind doing the releases, but the manual
> version update -- release -- revert version cycle is a chore.
>
> I was hoping that Maven could simplify this by allowing a project to
> declare a dependency on LATEST or 1.0-LATEST and have the maven release
> plugin resolve this to the actual latest released version available in
> the repository. The subsequent fully resolved pom would then be
> uploaded to the internal repository and the pom left in source control
> still references LATEST.
>
> Does maven already support something like this or would others find this
> useful?
Having a LATEST concept would be very useful for something like
continuous integration builds, where the desire is for a project to
depend on the latest version of another project (release or snapshot),
rather than a specific version of another project, so that you can see
what errors have been introduced or that should be allowed for.
Having said that, it makes no sense to have the release plugin care
about LATEST, because by definition, building against LATEST isn't
repeatable, and in order for there to be a release, you need the build
to be repeatable.
Regards,
Graham
--