investigate if non-semver system versions are fine

[iliana]

Requested by @askfongjojo in the huddle this morning.

Ideally the next system version would be named "v4". We set a system version in the package job:

omicron/.github/buildomat/jobs/package.sh

Lines 39 to 41 in 73c3571

	COMMIT=$(git rev-parse HEAD)
	VERSION="1.0.3-0.ci+git${COMMIT:0:11}"
	echo "$VERSION" >/work/version.txt

This is currently a semver. Need to validate whether this is treated as an opaque string or is actually parsed as semver and compared in current software.

[iliana]

There is also a larger release engineering question of how to differentiate between pre-release artifacts that are generated from some arbitrary commit, and what the actual resulting version is. Ideally this would happen during artifact signing.

If we determine it is too difficult to move to an integer version in the repo itself, we can move to e.g. 4.0.0-whatever.

[askfongjojo]

@iliana: Thank you for filing this ticket to track the version question/investigation!

[askfongjojo]

Hey @iliana, it looks like we may be close to having a version 4 going out. It'll be great if we can bump the version string to a higher number today (4.0.0-whatever can work too! We just need it to be different from 1.0.3 - the one already deployed to customer racks). Thanks!

[iliana]

system_version is declared across wicket, tufaceous-lib, and nexus as a SemverVersion. I think it is safe to say that we will need to keep it a semver for now; let's do 4.0.0 plus the current CI commit suffix we're using.

This does give us the opportunity to do point releases in the future if we decide we need to (as long as they comply with semver, lol).

[iliana]

Cross-referencing #4437; the investigation this issue calls for is complete.