I was explaining a proposed build system (Gradle/Artifactory/Jenkins/Chef) to one of our senior architects, and he made a comment to me that I sort of disagree with, but am not experienced enough to really weigh-in on.
This project builds a Java library (JAR) as an artifact to be reused by other teams. For versioning, I'd like to use the semantic approach of:
patch indicates bug/emergency fixes,
minor indicates backwards-compatible releases, and
major indicates either massive refactorings of the API and/or backwards-incompatible changes.
As far as delivery goes here is what I want: a developer commits some code; this triggers a build to a QA/TEST environment. Some tests are ran (some automated, some manual). If all tests pass, then a production build publishes the JAR to our in-house repo. By this point the JAR should be versioned properly, and my thinking was to use the
build.number that is automatically generated and provided by our CI tool to act as the patch number.
Thus, the versioning would actually be:
build.number is provided by the CI tool.
The architect dismissed this, saying that using the CI build number was an "abuse" of semantic versioning.
My question is: is this correct, and if so, why? And if not, why not?