You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@tesla.io> on 2012/11/13 21:38:23 UTC
https://jira.codehaus.org/browse/MNG-1304
This is a long-standing issue, but I think a document and standard has emerged that I think is reasonable. How do people feel about trying to adhere to:
http://semver.org
and moving toward using this as our standard versioning documentation?
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Jörg Schaible <jo...@gmx.de>.
Jason van Zyl wrote:
> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
Well, it sounds nice, but look at Apache commons and you'll see that it
fails in practice regarding X. If we had gone from
org.apache.commons:commons-lang:2.2.1 to org.apache.commons:commons-
lang:3.0.0 we would have been all into jar hell. Therefore a change in X in
Apache commons means new artifactId and new package name (if we cannot
provide compatible APIs) to allow 2.x and 3.x version to be used side-by-
side (in classpath and as dependency).
Just my 2¢,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Mark Hobson <ma...@gmail.com>.
+1
Standardisation on version semantics is key to dependency management.
Mark
On 13 Nov 2012, at 20:38, Jason van Zyl <ja...@tesla.io> wrote:
> This is a long-standing issue, but I think a document and standard has emerged that I think is reasonable. How do people feel about trying to adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1
On Tue, Nov 13, 2012 at 9:38 PM, Jason van Zyl <ja...@tesla.io> wrote:
> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Mark Derricutt <ma...@talios.com>.
When using ranges (as one should IMHO) you should never use .0 but always start with .1.
So that [1.0.0,2.0.0) actually works, otherwise the range picks up the 2.0.0-SNAPSHOT.
Mark
On 14/11/2012, at 10:35 AM, Dennis Lundberg <de...@apache.org> wrote:
> We added one exception though, and that is one that we might want to add
> here as well: we don't require Z if Z == 0. So instead of 2.2.0 you are
> allowed to use 2.2. For Maven core we have followed SemVer strictly, but
> most of our other components omit Z if it is 0, which it often if.
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Dennis Lundberg <de...@apache.org>.
On 2012-11-13 21:38, Jason van Zyl wrote:
> This is a long-standing issue, but I think a document and standard has emerged that I think is reasonable. How do people feel about trying to adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
SemVer is good. We moved from Apache commons versioning guidelines to
Semver 1.0.0 @work a while back.
We added one exception though, and that is one that we might want to add
here as well: we don't require Z if Z == 0. So instead of 2.2.0 you are
allowed to use 2.2. For Maven core we have followed SemVer strictly, but
most of our other components omit Z if it is 0, which it often if.
SemVer 1.0.0 is simpler than 2.0.0-rc.1 in that it does not cover
pre-releases or build numbers. Our current model sort of covers
pre-releases, but it doesn't cover build numbers very well.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Stephen Connolly <st...@gmail.com>.
+1 version incrementing logic should be a shared component not a part of
core.
Also I wonder if we shouldn't formalise the ability to scope versioning
systems per groupId:artifactId though that could merit being part of
core... And is somewhat political too
On Wednesday, 14 November 2012, Hervé BOUTEMY wrote:
> no
> core only needs to compare version
> core never need to calculate "next" version
>
> some plugines like release or versions need to try to guess which is the
> next
> one: nothing that belong to core IMHO
>
> Regards,
>
> Hervé
>
> Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit :
> > True... separate, but closely related. If we state that semver is the
> > recommended practice (and I believe that to be a good idea) .. the whole
> > tooling should work nicely with it. And that includes the use case I
> > mentioned..
> >
> > And yes.. maybe the version stuff should be part of core ... and then be
> > used e.g. by the release plugin as well as the versions plugin and
> > others..
> >
> > manfred
> >
> > On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
> > > These are 2 separate issues. As long as the bugfix/patch-part contains
> > > non-numeric values and Maven (actually Aether) still does a String
> match
> > > (apart from those special cases like alpha, beta, RC) we have to be
> very
> > > careful with calculating the next version.
> > > You could question if this kind of logic belongs in the
> > > maven-release-plugin, since it is more related to how Maven resolves
> > > versions.
> > >
> > > Robert
> > >
> > > Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
> > >
> > > <manfred@mosabuam.com <javascript:;>>:
> > >> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
> > >>> This is a long-standing issue, but I think a document and standard
> has
> > >>> emerged that I think is reasonable. How do people feel about trying
> to
> > >>> adhere to:
> > >>>
> > >>> http://semver.org
> > >>>
> > >>> and moving toward using this as our standard versioning
> documentation?
> > >>
> > >> I think that would be awesome. One of the things we would have to do
> is
> > >> fix the release plugin to work with 1.2.3-RC.2 as compared to
> 1.2.3-RC2.
> > >> Currently it does not correctly suggest the next version being
> > >> 1.2.3-RC.3
> > >> but rather goes to 1.2.4-RC.2
> > >>
> > >> This would also make it easier to explain the reasoning for the
> version
> > >> numbering since we could just point to the external docs as a best
> > >> practice.
> > >>
> > >> manfred
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> > >> For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Rex Hoffman <re...@e-hoffman.org>.
I had created a hack of the clirr plugin at a prior employer to compute the
next version number a few years ago.... (rejected by the mojo project, as
the owners didn't want to start breaking builds with clirr)
We had 50-60 jars and 20+ developers with a range of skill/java knowledge,
some remote.
I attempted to use sigtest instead as a plugin for the enforcer but ran out
of time/energy and switched jobs... but it's api was more than painful and
getting useful info about the deltas was more than a little difficult. I
understand the netbeans guys have pulled it off though.
The general behavior of the clirr hack was to download the last release
with a version number less then the projects (usually broke the build if
the version had already been released) and run clirr, again breaking the
build if the version didn't conform to what a few heuristics on top clirr
expected.
Of course this has limitations. An API that expects you to implement an
interface (never too hot of an idea) to interact with the API needs to have
that interface treated differently than if it was an interface clients were
expect to call and not implement.
My finding at every org I've been is that people screw up correct version
number incrementing (including myself). Changing the type input on a
method (unless its to a super class) breaks backwards compatibility, and
refactoring tools makes doing this all too easy.
Not sure how far you guys want to go with this, but I wouldn't mind putting
in some effort or resurrecting the support for clirr.
If maven embraces a standard like semver, building out even a partial
enforcement of the standard would go a long way to further adoption.
As far a version numbers stored in artifacts, perhaps allow an extension to
the build that turns on the restriction, and maybe a corresponding enforcer
rule?
Rex
On Wed, Nov 14, 2012 at 4:13 PM, Manfred Moser <ma...@mosabuam.com> wrote:
> Sure... not core then. But ideally some shared library that implements
> that so all plugins that need to do it can do it consistently the same..
>
> manfred
>
> On Wed, November 14, 2012 3:17 pm, Hervé BOUTEMY wrote:
> > no
> > core only needs to compare version
> > core never need to calculate "next" version
> >
> > some plugines like release or versions need to try to guess which is the
> > next
> > one: nothing that belong to core IMHO
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit :
> >> True... separate, but closely related. If we state that semver is the
> >> recommended practice (and I believe that to be a good idea) .. the whole
> >> tooling should work nicely with it. And that includes the use case I
> >> mentioned..
> >>
> >> And yes.. maybe the version stuff should be part of core ... and then be
> >> used e.g. by the release plugin as well as the versions plugin and
> >> others..
> >>
> >> manfred
> >>
> >> On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
> >> > These are 2 separate issues. As long as the bugfix/patch-part contains
> >> > non-numeric values and Maven (actually Aether) still does a String
> >> match
> >> > (apart from those special cases like alpha, beta, RC) we have to be
> >> very
> >> > careful with calculating the next version.
> >> > You could question if this kind of logic belongs in the
> >> > maven-release-plugin, since it is more related to how Maven resolves
> >> > versions.
> >> >
> >> > Robert
> >> >
> >> > Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
> >> >
> >> > <ma...@mosabuam.com>:
> >> >> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
> >> >>> This is a long-standing issue, but I think a document and standard
> >> has
> >> >>> emerged that I think is reasonable. How do people feel about trying
> >> to
> >> >>> adhere to:
> >> >>>
> >> >>> http://semver.org
> >> >>>
> >> >>> and moving toward using this as our standard versioning
> >> documentation?
> >> >>
> >> >> I think that would be awesome. One of the things we would have to do
> >> is
> >> >> fix the release plugin to work with 1.2.3-RC.2 as compared to
> >> 1.2.3-RC2.
> >> >> Currently it does not correctly suggest the next version being
> >> >> 1.2.3-RC.3
> >> >> but rather goes to 1.2.4-RC.2
> >> >>
> >> >> This would also make it easier to explain the reasoning for the
> >> version
> >> >> numbering since we could just point to the external docs as a best
> >> >> practice.
> >> >>
> >> >> manfred
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Manfred Moser <ma...@mosabuam.com>.
Sure... not core then. But ideally some shared library that implements
that so all plugins that need to do it can do it consistently the same..
manfred
On Wed, November 14, 2012 3:17 pm, Hervé BOUTEMY wrote:
> no
> core only needs to compare version
> core never need to calculate "next" version
>
> some plugines like release or versions need to try to guess which is the
> next
> one: nothing that belong to core IMHO
>
> Regards,
>
> Hervé
>
> Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit :
>> True... separate, but closely related. If we state that semver is the
>> recommended practice (and I believe that to be a good idea) .. the whole
>> tooling should work nicely with it. And that includes the use case I
>> mentioned..
>>
>> And yes.. maybe the version stuff should be part of core ... and then be
>> used e.g. by the release plugin as well as the versions plugin and
>> others..
>>
>> manfred
>>
>> On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
>> > These are 2 separate issues. As long as the bugfix/patch-part contains
>> > non-numeric values and Maven (actually Aether) still does a String
>> match
>> > (apart from those special cases like alpha, beta, RC) we have to be
>> very
>> > careful with calculating the next version.
>> > You could question if this kind of logic belongs in the
>> > maven-release-plugin, since it is more related to how Maven resolves
>> > versions.
>> >
>> > Robert
>> >
>> > Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
>> >
>> > <ma...@mosabuam.com>:
>> >> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
>> >>> This is a long-standing issue, but I think a document and standard
>> has
>> >>> emerged that I think is reasonable. How do people feel about trying
>> to
>> >>> adhere to:
>> >>>
>> >>> http://semver.org
>> >>>
>> >>> and moving toward using this as our standard versioning
>> documentation?
>> >>
>> >> I think that would be awesome. One of the things we would have to do
>> is
>> >> fix the release plugin to work with 1.2.3-RC.2 as compared to
>> 1.2.3-RC2.
>> >> Currently it does not correctly suggest the next version being
>> >> 1.2.3-RC.3
>> >> but rather goes to 1.2.4-RC.2
>> >>
>> >> This would also make it easier to explain the reasoning for the
>> version
>> >> numbering since we could just point to the external docs as a best
>> >> practice.
>> >>
>> >> manfred
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Hervé BOUTEMY <he...@free.fr>.
no
core only needs to compare version
core never need to calculate "next" version
some plugines like release or versions need to try to guess which is the next
one: nothing that belong to core IMHO
Regards,
Hervé
Le mardi 13 novembre 2012 14:28:18 Manfred Moser a écrit :
> True... separate, but closely related. If we state that semver is the
> recommended practice (and I believe that to be a good idea) .. the whole
> tooling should work nicely with it. And that includes the use case I
> mentioned..
>
> And yes.. maybe the version stuff should be part of core ... and then be
> used e.g. by the release plugin as well as the versions plugin and
> others..
>
> manfred
>
> On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
> > These are 2 separate issues. As long as the bugfix/patch-part contains
> > non-numeric values and Maven (actually Aether) still does a String match
> > (apart from those special cases like alpha, beta, RC) we have to be very
> > careful with calculating the next version.
> > You could question if this kind of logic belongs in the
> > maven-release-plugin, since it is more related to how Maven resolves
> > versions.
> >
> > Robert
> >
> > Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
> >
> > <ma...@mosabuam.com>:
> >> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
> >>> This is a long-standing issue, but I think a document and standard has
> >>> emerged that I think is reasonable. How do people feel about trying to
> >>> adhere to:
> >>>
> >>> http://semver.org
> >>>
> >>> and moving toward using this as our standard versioning documentation?
> >>
> >> I think that would be awesome. One of the things we would have to do is
> >> fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
> >> Currently it does not correctly suggest the next version being
> >> 1.2.3-RC.3
> >> but rather goes to 1.2.4-RC.2
> >>
> >> This would also make it easier to explain the reasoning for the version
> >> numbering since we could just point to the external docs as a best
> >> practice.
> >>
> >> manfred
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Olivier Lamy <ol...@apache.org>.
2012/11/13 Manfred Moser <ma...@mosabuam.com>:
> True... separate, but closely related. If we state that semver is the
> recommended practice (and I believe that to be a good idea) .. the whole
> tooling should work nicely with it. And that includes the use case I
> mentioned..
>
> And yes.. maybe the version stuff should be part of core ... and then be
> used e.g. by the release plugin as well as the versions plugin and
> others..
uhm this means plugins will be dependent of core releases in case of issues ?
Perso I would prefer to avoid that and have a separate library with
his own release cycle for that
>
> manfred
>
> On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
>> These are 2 separate issues. As long as the bugfix/patch-part contains
>> non-numeric values and Maven (actually Aether) still does a String match
>> (apart from those special cases like alpha, beta, RC) we have to be very
>> careful with calculating the next version.
>> You could question if this kind of logic belongs in the
>> maven-release-plugin, since it is more related to how Maven resolves
>> versions.
>>
>> Robert
>>
>> Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
>> <ma...@mosabuam.com>:
>>
>>> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
>>>> This is a long-standing issue, but I think a document and standard has
>>>> emerged that I think is reasonable. How do people feel about trying to
>>>> adhere to:
>>>>
>>>> http://semver.org
>>>>
>>>> and moving toward using this as our standard versioning documentation?
>>>
>>> I think that would be awesome. One of the things we would have to do is
>>> fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
>>> Currently it does not correctly suggest the next version being
>>> 1.2.3-RC.3
>>> but rather goes to 1.2.4-RC.2
>>>
>>> This would also make it easier to explain the reasoning for the version
>>> numbering since we could just point to the external docs as a best
>>> practice.
>>>
>>> manfred
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Manfred Moser <ma...@mosabuam.com>.
True... separate, but closely related. If we state that semver is the
recommended practice (and I believe that to be a good idea) .. the whole
tooling should work nicely with it. And that includes the use case I
mentioned..
And yes.. maybe the version stuff should be part of core ... and then be
used e.g. by the release plugin as well as the versions plugin and
others..
manfred
On Tue, November 13, 2012 2:05 pm, Robert Scholte wrote:
> These are 2 separate issues. As long as the bugfix/patch-part contains
> non-numeric values and Maven (actually Aether) still does a String match
> (apart from those special cases like alpha, beta, RC) we have to be very
> careful with calculating the next version.
> You could question if this kind of logic belongs in the
> maven-release-plugin, since it is more related to how Maven resolves
> versions.
>
> Robert
>
> Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
> <ma...@mosabuam.com>:
>
>> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
>>> This is a long-standing issue, but I think a document and standard has
>>> emerged that I think is reasonable. How do people feel about trying to
>>> adhere to:
>>>
>>> http://semver.org
>>>
>>> and moving toward using this as our standard versioning documentation?
>>
>> I think that would be awesome. One of the things we would have to do is
>> fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
>> Currently it does not correctly suggest the next version being
>> 1.2.3-RC.3
>> but rather goes to 1.2.4-RC.2
>>
>> This would also make it easier to explain the reasoning for the version
>> numbering since we could just point to the external docs as a best
>> practice.
>>
>> manfred
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Robert Scholte <rf...@apache.org>.
These are 2 separate issues. As long as the bugfix/patch-part contains
non-numeric values and Maven (actually Aether) still does a String match
(apart from those special cases like alpha, beta, RC) we have to be very
careful with calculating the next version.
You could question if this kind of logic belongs in the
maven-release-plugin, since it is more related to how Maven resolves
versions.
Robert
Op Tue, 13 Nov 2012 22:22:48 +0100 schreef Manfred Moser
<ma...@mosabuam.com>:
> On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
>> This is a long-standing issue, but I think a document and standard has
>> emerged that I think is reasonable. How do people feel about trying to
>> adhere to:
>>
>> http://semver.org
>>
>> and moving toward using this as our standard versioning documentation?
>
> I think that would be awesome. One of the things we would have to do is
> fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
> Currently it does not correctly suggest the next version being 1.2.3-RC.3
> but rather goes to 1.2.4-RC.2
>
> This would also make it easier to explain the reasoning for the version
> numbering since we could just point to the external docs as a best
> practice.
>
> manfred
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
Posted by Manfred Moser <ma...@mosabuam.com>.
On Tue, November 13, 2012 12:38 pm, Jason van Zyl wrote:
> This is a long-standing issue, but I think a document and standard has
> emerged that I think is reasonable. How do people feel about trying to
> adhere to:
>
> http://semver.org
>
> and moving toward using this as our standard versioning documentation?
I think that would be awesome. One of the things we would have to do is
fix the release plugin to work with 1.2.3-RC.2 as compared to 1.2.3-RC2.
Currently it does not correctly suggest the next version being 1.2.3-RC.3
but rather goes to 1.2.4-RC.2
This would also make it easier to explain the reasoning for the version
numbering since we could just point to the external docs as a best
practice.
manfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org