test version number calculation

[oocube]

To improve on #616 Unclear oolite Version Numbers

[mcarans]

Is this PR under development? If you're experimenting, I suggest converting it to draft (which still allows workflows to run) .

[oocube]

I am confident that version numbers are calculated in a good way. If you search the forum for 'semver' you will see the topic is not new but was always doubted or rejected. That's why I created a build step to calculate the version number only. I intend to merge it so everyone can see what the new numbering scheme would look like.

To make these version numbers actually go into the builds I will need your help. Somehow the two variables need to be passed to the correct build script but also be used inside. And I suggest we'd do this last change on a branch after this one has merged.

BTW, I have no explanation why the windows test failed. This branch did not change anything relating to artifact generation or publishing.

[mcarans]

I can see these variables in the build of this PR:

assemblySemFileVer=1.93.1.0
assemblySemVer=1.93.1.0
branchName=pull/619/merge
buildMetaData=
commitDate=2026-05-04
commitsSinceVersionSource=54
escapedBranchName=pull-619-merge
fullBuildMetaData=Branch.pull-619-merge.Sha.c0d5898d03a3d599d10ae12b9e8cc8c6692d3f26
fullSemVer=1.93.1-PullRequest619.54
informationalVersion=1.93.1-PullRequest619.54+Branch.pull-619-merge.Sha.c0d5898d03a3d599d10ae12b9e8cc8c6692d3f26
major=1
majorMinorPatch=1.93.1
minor=93
patch=1
preReleaseLabel=PullRequest619
preReleaseLabelWithDash=-PullRequest619
preReleaseNumber=54
preReleaseTag=PullRequest619.54
preReleaseTagWithDash=-PullRequest619.54
semVer=1.93.1-PullRequest619.54
sha=c0d5898d03a3d599d10ae12b9e8cc8c6692d3f26
shortSha=c0d5898
uncommittedChanges=0
versionSourceDistance=54
versionSourceIncrement=None
versionSourceSemVer=1.93.1
versionSourceSha=ca6d91a33b7acd5b80a307a9f12643281a36f423
weightedPreReleaseNumber=30054

Which one do you intend gets used?

[oocube]

Please have a peek at #616. It is these two:

GitVersion_SemVer
PROJECTNAME

[mcarans]

I like the idea of using semver, but I think this is best done by calling a command line semver tool from the script: https://github.com/OoliteProject/oolite/blob/master/ShellScripts/common/get_version.sh (or in future directly from meson or cmake).

gitversion needs the .NET framework. I would prefer a single executable such as https://github.com/restechnica/semverbot or https://github.com/caarlos0/svu

AI says "If you want the exact same version numbers as GitVersion based on your branch names, go with Semverbot. If you are willing to move to a more modern "tag-distance" logic that is much faster, svu is the gold standard for Go-based versioning."

[oocube]

Gitversion remembers already used version numbers based on tags in the repository. I see your scripts running multiple times after each push which would generate too many version numbers. That's why I placed version number calculation into a separate job.

I am not against the tools you mention. How about creating another branch and see how it works?

[mcarans]

Yes I'll need to look into ensuring the version doesn't get repeatedly incremented.

I'm learning more about this topic via AI. The latest way to do things which I think you might like are "conventional commits".

"Conventional Commits is a lightweight specification for your commit messages that makes them both human-readable and machine-processable. It has largely become the "modern" industry standard because it replaces the "guesswork" of branch-based versioning with a data-driven, automated workflow.

1. The Structure

The format is simple: <type>(<scope>): <description>

• feat: A new feature (maps to a Minor version bump).
• fix: A bug fix (maps to a Patch version bump).
• BREAKING CHANGE (or adding a ! after the type): A change that breaks backward compatibility (maps to a Major version bump).
• Other types: chore, docs, style, refactor, perf, test (usually don't trigger a version bump).

2. Why is it considered the "Most Modern" way?

While branch-based versioning (like GitVersion) was popular for a long time, the industry has shifted toward Conventional Commits for several reasons:

A. Automated Versioning & Changelogs

Because the "intent" of the change is baked into the commit message itself, tools like semantic-release or release-please can:

• Scan your git history.
• Determine if the next version should be 1.0.1 or 1.1.0.
• Automatically generate a CHANGELOG.md that lists exactly which features and fixes were added.

B. Platform Agnostic

Unlike GitVersion, which requires a .NET runtime or complex configurations to understand your branching strategy, Conventional Commits works anywhere. Whether you are in a C++ project using Meson, a Web app using Node, or a Systems tool in Go, the logic remains identical.

C. Better for Trunk-Based Development

Modern teams are moving away from long-lived feature branches (GitFlow) toward Trunk-Based Development, where everyone pushes to main frequently.

• Branch-based versioning struggles here because there are no "feature branches" to look at.
• Conventional Commits thrives here because every single commit clearly states its impact on the version number."

AI also suggested a tool called GoReleaser which despite the name, is actually a tool that both handles version and publishes releases on multiple platforms in multiple package managers (msix, arch, deb, rpm, flatpak etc.) regardless of language. That could be something to look into in future but possibly a bit ambitious now.

The svu tool I mentioned previously also supports "conventional commits".

Which approach works best for Oolite development is probably best opened to a wider discussion as these approaches won't work unless there is buy in from devs.

[oocube]

This discussion should happen in issue 616. If we ditch this branch it is lost.

[Zireael07]

@oocube What do you mean "if we ditch this branch it is lost"? Closed PRs are still accessible on github and discussion in them can be continued (unless a repo uses some sort of a stalebot/lockbot)

[oocube]

@Zireael07 Technically you are right. You can still find issue 619, but will anyone really do so?

It will get really nasty if we have a couple of attempts, say three or four branches and our discussion on the topic is distributed amongst them. Hence I suggested to keep the discussion on issue 616.