Immersive Engineering

Immersive Engineering

134M Downloads

Illegal Jenkins Version Numbering

BluSunrize opened this issue ยท 6 comments

commented

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

commented

Apparently BUILD_NUMBER is the env variable on jenkins, according to SkySom.
We should try that.

commented

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).

commented

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.

commented

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.

commented

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.

commented

i fix