fiunchinho
commented
5 years ago We used a similiar approach on my former employer, but we used the current date when the build was being made, instead of the count of commits in the branch.
I think the suggested approach it's better since:
- has no dependencies on external tooling
- no need for manual intervention as opposed to releasing a new major/minor version when using jx-release-version
- it's a commit: no need to go and see what commit is 1.2.3 referring to.
jglick
sboardwell
jenkins-x-bot
Reading this post by @fiunchinho reminds that
jx-release-versionand Git tags withjx step tagare unnecessary overkill for (IMO) all users of the Kubernetes (CD) buildpacks and the great majority of users of the Classic buildpacks. Even if you buy into semver’s idea of compatibility guarantees (and I think it is wishful thinking), that is only meaningful for authors of library components with public distribution, such as Java APIs uploaded to Maven Central, which is certainly not the principal use case for JX. The Git tags are also created on special commits off themasterbranch, which is awkward sincegit pullwill not find them by default.In JEP-305 I chose a version format which can be deterministically computed from the Git repository itself¹, without needing special tools, version number vending, Git push credentials, etc.; and which produces versions which compare naturally in various senses. I would propose that
jx-release-versionandjx step tagbe deprecated, and that the buildpacks simply set²You will get a numeric component which is guaranteed to be monotonically increasing in the
masterbranch from which releases are cut; a nonnumeric component for the commit hash of amaster-branch Git commit that can be easily pasted intogitcommands; and no unused0.0.or0.1.prefix clutter that is meaningless in a CD environment.Sample change (from a real project):
¹Regardless of refs (works on a detached
HEAD), but may not work in a shallow clone, which Knative Build used last I checked—noticed because it broke Sonar scans, worked around via²In the case of the Maven pack,
mvn versions:setcould if desired be skipped in favor of a Maven extension like that in JEP-305, though this would require changes to the quickstarts as well.