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?