Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <94a9c8e1a9185960734cdf033c1640ad.squirrel@www.mosabuam.com>
References: <20ACD123-E135-4D9C-B04E-4926B07C9ABB@tesla.io>
	<op.wnqfmmb0kdkhrr@columbia>
	<07d3aa7b983b2bac1470eb07a63fe4e2.squirrel@www.mosabuam.com>
	<1527998.OnLFzz9ZRz@bigmax>
	<94a9c8e1a9185960734cdf033c1640ad.squirrel@www.mosabuam.com>
Date: Wed, 14 Nov 2012 16:51:50 -0800
Message-ID: 
 <CANZ6mp-qA7XFgdeXcEJiM=t7Bg-eEYOpBLXG-mrE0qbzpBqEuw@mail.gmail.com>
Subject: Re: https://jira.codehaus.org/browse/MNG-1304
From: Rex Hoffman <rex@e-hoffman.org>
To: Maven Developers List <dev@maven.apache.org>, manfred@mosabuam.com
Content-Type: multipart/alternative; boundary=e89a8f22bd8973fcae04ce7e0e8f

--e89a8f22bd8973fcae04ce7e0e8f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <manfred@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=C3=A9 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 th=
e
> > next
> > one: nothing that belong to core IMHO
> >
> > Regards,
> >
> > Herv=C3=A9
> >
> > Le mardi 13 novembre 2012 14:28:18 Manfred Moser a =C3=A9crit :
> >> True... separate, but closely related. If we state that semver is the
> >> recommended practice (and I believe that to be a good idea) .. the who=
le
> >> 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 contai=
ns
> >> > 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>:
> >> >> 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 tryin=
g
> >> 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 d=
o
> >> 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
>
>

--e89a8f22bd8973fcae04ce7e0e8f--