Closed jglick closed 4 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:
Indeed you can also simply use a timestamp (optionally with a short commit hash in an informative section). The drawback is that the version is not then a function of your sources; it is essentially arbitrary. While for JEP-305 this distinction was critical, for the K8s buildpack a timestamp might be fine, since the version is merely an identifier of a chart to deploy—there is no expectation that it will be used in a build system dependency.
@jstrachan mentions that there is a new system for master
tags used in Tektōn mode. This still feels like overkill for the typical uses of JX—why do we need tags at all when we can pick a reasonable version number and deploy it on master
commits without further ado?
Curious as to whether and how something like this would work with an approach such as GitFlow? i.e. creating a release branch from develop, fine tuning, etc, then pushing to master...
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Provide feedback via https://jenkins-x.io/community.
/close
@jenkins-x-bot: Closing this issue.
Reading this post by @fiunchinho reminds that
jx-release-version
and Git tags withjx step tag
are 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 themaster
branch, which is awkward sincegit pull
will 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-version
andjx step tag
be deprecated, and that the buildpacks simply set²You will get a numeric component which is guaranteed to be monotonically increasing in the
master
branch from which releases are cut; a nonnumeric component for the commit hash of amaster
-branch Git commit that can be easily pasted intogit
commands; 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:set
could 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.