For a long time I would like to discuss current maven’s naming notation. Better later than never.
currently you are exploring follow model:
WDYT?
Laird,
thank you for your cents, could you please give a reference, where this practice is discussed. Yeah, I see, Maven Project itself uses 3.0.3-SNAPSHOT convention. But I know the communities that do not follow this pattern, i.e. Apache Wicket. I remember the discussion (I did never personally took part) why they switch from 1.3.0-SNAPSHOT to 1.3-SNAPSHOT. Maven community itself often use 2-number notation, https://github.com/apache/maven-scm/blob/trunk/pom.xml.
What on your opinion is wrong with change naming? I guess you are actively develop your own extensions for liquibase. May be it will break your environment, how, could you please describe?
regards, Oleg
I use the 3 digit notation because the major digit is only used for changelog-breaking releases, which should be kept to an absolute minimum. Therefore, the minor digit is for normal larger releases and the patch release is for smaller updates to the larger releases.
I’m still thinking we should keep wtih the 3 digit snapshot naming. I don’t see it as a huge deal,it gives a bit more information on exactly what version it is based on. Once I get a better feel for git and branches and how that impacts how we handle versions, I may change my mind. But for now I think it’s best to just stick with how it is.
Nathan
This proposal goes against the way Maven is used in every other open source project out there. Consequently for whatever it is worth I disagree with it very strongly. My two cents.
Best,
Laird
Hi, Oleg; my opinion is based on my desire to look at the SNAPSHOT version and to know immediately what the next release number will be. It’s what (at my job) my developers expect as well. I think you’ll discover that most large projects at any rate follow this convention.
Having said that, it is only a convention.
Best,
Laird
Hi Laird,
What "most large projects " you mean? On your advice I did research about the naming convention of the projects from the Apache Foundation. I did looking at the maven plugins (https://github.com/apache/maven-plugins) and from codehaus mojo project (http://svn.codehaus.org/mojo/trunk/mojo).
I results are diametrical contrary. In the maven-plugins from 43 project only 6 using 3-numbers convention, in the codehaus mojo only 8 from 88.
C:\opensource\org\codehaus\mojo\trunk\findbugs-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\gwt-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\jboss-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\jpox-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\weblogic-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\xml-maven-plugin\pom.xml C:\opensource\org\codehaus\mojo\trunk\xmlbeans-maven-plugin\pom.xml
Regards, Oleg
3-digit model complicates managing the project in context of main lib / dependent extensions libs. Especially if you want introduce a new features in main lib and want to be sure all extensions are not broken with new API or other changes in the main lib. This could lead you to either advance the ext’s versions to new one, same as the main advance number (which is IMO cumbersome and disappointing, I would like the extension have to get a new version number only when it is added a new feature/bugfix itself) or to leave the extensions compatibility/testability on the outdated state.
It make more worse if you need to implement new features or especially with refactoring the main lib’s functionality in a new branch. Especially if you have not only reference to the SNAPSHOT version, which could be fixed with maven release plugin, but in the unit/integrations test too. Looking through all integration test and fixing it could turns to the nightmare.
Again, I did never receive a reasonable argument, which the benefit brings knowing the next version? Using git locally you can enumerate in any time which tags/branches are released without ever having access to the main repo. Also you don’t bind yourself with promising next version should be. I.e. currently you are promising that after 2.0.2 will be 2.0.3 in any case. But generally it is not true! You could not ever release 2.0.3, but merge to 2.1 branch and continue work on that. Especially it would be helpful on the alfa/beta/rc stage.
I see more benefits follow as little-number convention as possible. On my taste I would use 0-number convention in the master/trunk branch, simple SNAPSHOT. It would guarantee of sync the main/ext compatibility/tests at any time you working on the project in the concurrent manner (include development new feature/refactoring) along with working in the future. But I guess it cause much more reluctance as a 2-number convention
my 2c, Oleg
BTW, why maven release plugin prefer 3-digit notation?
It does probably come down purely to a matter of taste, but I agree with laird. Since we use 3 digits in our versions, it helps to know (especially for those using maven) which upcoming version a snapshot is of. The maven release plugin likes it best when they full version is included with the snapshot, and I think the more descriptive, the better.
I would guess (not looking extensively) that the two-digit snapshots are for when they are snapshots for the next minor version, not for the next snapshot. Since we have not yet created a 2.0 branch, 2.0.2 development is in trunk/master and so the version is 2.0.2-SNAPSHOT. When we begin 2.1.0 development in trunk, we could change it to 2.1-SNAPSHOT or 2.1.0-SNAPSHOT. At that point even for maven it probably doesn’t care, but I think it’s good to stick with 2.1.0 for consistency, still.
Nathan
