Illegal Jenkins Version Numbering
BluSunrize opened this issue ยท 6 comments
Our jenkins buildnumbers are not valid semantic versions, which breaks automatic version handlers.
Usually this isn't an issue, since noone uses our jenkins, but cpw has trouble with it on ForgeCraft.
Our current number is:
<major>.<minor>-<git hash>
If we are able to get the current jenkins job number (from an env variable maybe?) I would suggest changing it to
<major>.<minor>-pre.<jenkins number>
Opinions & input?
@malte0811 @SkySom
Apparently BUILD_NUMBER
is the env variable on jenkins, according to SkySom.
We should try that.
I would prefer the git-tag based approach suggested in FC. It gives a bit more reference on how much newer a build is compared to the official build. We can tag the current latest releases manually, and I can look into making a gradle task that handles everything that needs to be done for a release (increment version_buildnumber
, add a tag, run a build, maybe even commit the changelogs+gradle.properties
).
The problem with doing a tag based approach is that git describe
gives us the number of commits since that tag. Meaning we would have to include the previous build number to make it unique.
I don't want that, because then we have something like 110-9, which is 9 commits after Build 110, but looks like its a 110 build, when really it is a prerelease for the next version.
That next version doesn't have a build number though, because we only increment that on release.
That's one of the things we changed in regards to Jenkins numbering, we don't have the build number in there anymore. If we use the git based approach, we would need to, in order to keep versions unique.
Increasing build number after build is what we used to do, but we specifically moved away from that, because it means incrementing it by 3 every time (for 1.14, 1.15 and 1.16) and we may not need to release all three of those at the same time in the future.
Instead we now increase it when we do the build. Hence why including it in Jenkins is a problem.
Basically the way I do it is I turn up the build number right after I release, so things prior to a version are <major>.<minor>.<bug>-SNAPSHOT.<build_number>
and SNAPSHOTS are pres for a version. but similar works. I've never really had needs for knowing how many builds it is.