Re: https://jira.codehaus.org/browse/MNG-1304
2012/11/13 Manfred Moser manf...@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 manf...@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-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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
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 manf...@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-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
Re: https://jira.codehaus.org/browse/MNG-1304
+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 manf...@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-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: https://jira.codehaus.org/browse/MNG-1304
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 manf...@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-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
Re: https://jira.codehaus.org/browse/MNG-1304
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 manf...@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 manf...@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-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
Re: https://jira.codehaus.org/browse/MNG-1304
+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
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
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 manf...@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-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
Re: https://jira.codehaus.org/browse/MNG-1304
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 manf...@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-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
Re: https://jira.codehaus.org/browse/MNG-1304
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: https://jira.codehaus.org/browse/MNG-1304
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 denn...@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
+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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
