I've been using the 4 digit versions with the release plugin for the last 6 years or so. I've never used ranges, as I either thought there was a problem with them and the release plugin. So if 1.0.0.10 comes before 1.0.0.9, wouldn't 1.0.10 therefor come before 1.0.9?
-Chris On Sun, Mar 16, 2014 at 8:55 PM, Robert Scholte <rfscho...@apache.org>wrote: > Hi Chris, > > the input is a String, so it's possible to support as many digits as you > can. > However, an ArtifactVersion [1] doesn't support that much digits, so I'll > lock it to 3 to keep the current Maven versioning style. When working with > ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second dot > can't be handled as an Integer, so it is handled as a String. For that > reason the Maven Release plugin shouldn't be able to generate such > versions. If you are aware of this and never use ranges, you are safe (but > not your consumers ;) ) > > Robert > > [1] http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/ > org/apache/maven/artifact/versioning/ArtifactVersion.html > > Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham < > chrisgw...@gmail.com>: > > > Hi Robert. >> >> Just a request, can you please test to 4 (that I always use) and 5 digits, >> that sometimes I have to use? >> >> Ie >> 1.0.0.1-SNAPSHOT >> and >> 1.0.0.1.1-SNAPSHOT >> >> If you can, it might save me quite a bit of work later on. The release >> plugin copes with 4 digits, but not 5 (from what I can see in the code). >> >> Ta. >> >> -Chris >> >> >> >> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte <rfscho...@apache.org >> >wrote: >> >> To say it in your own words: IMHO I think you're wrong here ;) >>> >>> Version policy is about calculating the next version based on an input >>> version. >>> These are valid examples: >>> default policy: >>> getReleaseVersion("1-SNAPSHOT") = 1 >>> getReleaseVersion("1.0-SNAPSHOT") = 1.0 >>> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0 >>> getDevelopmentVersion("1") = 2-SNAPSHOT >>> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT >>> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT >>> >>> odd-even >>> getReleaseVersion("1.0-SNAPSHOT") = 1.1 >>> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT >>> >>> the metadata gives the following opportunity: >>> suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that case >>> you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 -> >>> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT >>> >>> I think it's weird to depend the policy on the GAV. Just choose a proper >>> policy for your project. >>> >>> I also think that the ArtifactResolver is not required here. >>> It's like instead of passing a string-based version, you'd like to pass >>> an >>> artifact and extract it's version. >>> My idea is the other way around: extract the version from the artifact >>> first and pass that to the policy. >>> I would expect it to be the version in the pom.xml. If you want to check >>> it, use an enforcer rule or something like that. >>> >>> We should try to keep the task of this class as simple as possible. >>> >>> Robert >>> >>> Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi < >>> simonetrip...@apache.org>: >>> >>> >>> Hi again Robert, >>> >>>> >>>> sorry for bugging - I hope I don't :P - but I notice Metadata also has >>>> a very limited subset of informations about the ongoing released >>>> artifact. >>>> IMHO informations such us packaging and classifier should be part of >>>> that data set - maybe I am wrong and work around that? >>>> >>>> TIA, All the best! >>>> -Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://twitter.com/simonetripodi >>>> >>>> >>>> On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte <rfscho...@apache.org> >>>> wrote: >>>> >>>> Hi Simone, >>>>> >>>>> for that reason I've added the Metadata, from which you can get the >>>>> latest >>>>> released artifact. >>>>> I really hope you don't need the ArtifactResolver. >>>>> >>>>> Robert >>>>> >>>>> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi >>>>> <simonetrip...@apache.org>: >>>>> >>>>> >>>>> Hi again Robert, >>>>> >>>>>> >>>>>> in one of my VersionPolicy implementations, I need to resolve the >>>>>> latest release artifact - then I have a tool to compare the bytecodes >>>>>> and automatically understand which is the release number. >>>>>> >>>>>> Question is: while I need an ArtifactResolver, I also need >>>>>> ArtifactRepository for local/remotes that, inside a MOJO, would be get >>>>>> via the code below... what are the related Plexus annotations, in >>>>>> order to obtain the same components? >>>>>> >>>>>> TIA, all the best! >>>>>> -Simo >>>>>> >>>>>> @Parameter(required = true, defaultValue = "${localRepository}", >>>>>> readonly = true) >>>>>> private ArtifactRepository localRepository; >>>>>> >>>>>> @Parameter(required = true, defaultValue = >>>>>> "${project.remoteArtifactRepositories}", readonly = true) >>>>>> private List<ArtifactRepository> remoteRepositories; >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://twitter.com/simonetripodi >>>>>> >>>>>> >>>>>> On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte <rfscho...@apache.org >>>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi Simone, >>>>>>> >>>>>>> I still have to find a solution for the VersionParseException which >>>>>>> can >>>>>>> be >>>>>>> thrown with the current implementation of DefaultVersionInfo. I >>>>>>> probably >>>>>>> have to add it to both methods of VersionPolicy >>>>>>> >>>>>>> Your custom implementation will look something like: >>>>>>> >>>>>>> @Component( role = VersionPolicy.class, hint = "tripodi" ) >>>>>>> public class TripodiVersionPolicy implements VersionPolicy { >>>>>>> // your stuff >>>>>>> } >>>>>>> >>>>>>> The plugin will get parameters like projectVersionPolicyId and/or >>>>>>> dependencyVersionPolicyId. >>>>>>> At least, that's my idea right now to split it up per type. This way >>>>>>> implementations can stay as clean as possible. >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi >>>>>>> <simonetrip...@apache.org>: >>>>>>> >>>>>>> >>>>>>> Hi again Robert, >>>>>>> >>>>>>>> >>>>>>>> new APIs look reasonable and easily extensible to me, thanks for >>>>>>>> putting >>>>>>>> effort on that! >>>>>>>> I maybe missed something but I didn't notice how they are integrated >>>>>>>> in >>>>>>>> the >>>>>>>> core module... >>>>>>>> TIA all the best! >>>>>>>> -Simo >>>>>>>> >>>>>>>> >>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>> http://twitter.com/simonetripodi >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte < >>>>>>>> rfscho...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Simone, >>>>>>>> >>>>>>>>> >>>>>>>>> I've added a new module for Maven release policies including my >>>>>>>>> idea >>>>>>>>> of >>>>>>>>> how the API should look like. >>>>>>>>> Although one of my suggestions to specify this as an implementation >>>>>>>>> in >>>>>>>>> the >>>>>>>>> plugin configuration, I now prefer to use it as a component. >>>>>>>>> Downside >>>>>>>>> is >>>>>>>>> that you can't use a pojo, you'll need to add Plexus annotations >>>>>>>>> and >>>>>>>>> generate the descriptor. However, now you can inject other >>>>>>>>> components >>>>>>>>> a.k.a >>>>>>>>> requirements. Since this might become quite complicated, injection >>>>>>>>> is >>>>>>>>> probably the preferred way. >>>>>>>>> I probably need more info in the PolicyRequest to support the >>>>>>>>> current >>>>>>>>> behavior, but this is just a start. >>>>>>>>> This should be a good start for you too. Let me know if this will >>>>>>>>> work >>>>>>>>> with your requirements. >>>>>>>>> >>>>>>>>> best, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi < >>>>>>>>> simonetrip...@apache.org>: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Rob! :) >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> indeed it has been a very long while, so sorry for that :( >>>>>>>>>> >>>>>>>>>> OK I understand your PoV, count on me if you want to co-operate - >>>>>>>>>> I >>>>>>>>>> need >>>>>>>>>> that feature as well in order to make the release-plugin able to >>>>>>>>>> generate >>>>>>>>>> that version using a tool, but without exposing such APIs that >>>>>>>>>> allow >>>>>>>>>> me >>>>>>>>>> plugging different versioning systems, I cannot do it :) >>>>>>>>>> >>>>>>>>>> Many thanks in advance and have a nice weekend! >>>>>>>>>> All the best! >>>>>>>>>> -Simo >>>>>>>>>> >>>>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>>>> http://twitter.com/simonetripodi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte < >>>>>>>>>> rfscho...@apache.org >>>>>>>>>> >wrote: >>>>>>>>>> >>>>>>>>>> Hi Simone, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It's been a while, so I'll need to have another look at this. >>>>>>>>>>> At first glance I'm not yet happy with the suggested API. >>>>>>>>>>> I'd need to make some time so come with a final solution. >>>>>>>>>>> >>>>>>>>>>> Robert >>>>>>>>>>> >>>>>>>>>>> Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi < >>>>>>>>>>> simonetrip...@apache.org>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi all mates, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am in a phase where I could get benefit of that feature as >>>>>>>>>>>> well >>>>>>>>>>>> (and, >>>>>>>>>>>> since I am still in the committer list, I can provide some help >>>>>>>>>>>> here) >>>>>>>>>>>> so I >>>>>>>>>>>> would like to push it :P >>>>>>>>>>>> >>>>>>>>>>>> @Robert: before merging the contribution we received in JIRA, >>>>>>>>>>>> I'd >>>>>>>>>>>> kindly >>>>>>>>>>>> ask if you had a better idea if new API has to be in >>>>>>>>>>>> the maven-release-manager or in a separate module. >>>>>>>>>>>> >>>>>>>>>>>> Many thanks in advance, all the best! >>>>>>>>>>>> -Simo >>>>>>>>>>>> >>>>>>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>>>>>> http://twitter.com/simonetripodi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>> --------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>> --------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>> --------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>> --------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
