Use consistent versioning about wizznic

[DusteDdk]

Hi, thank you very much for the comprehensive feedback, I'm going to go with semantic then, starting at version 400, that will make things easier. :) I think I'll update the things later and make a new release, version 400.1.0. I'll also update the documentation to reflect that this is used.

[DusteDdk]

Thanks for your input, and yes, you are right, it's quite a mess indeed!
Build-numbers don't quite cut it, since downstream builds would be different numbers.
GIT sha's are nice, but one can't easily tell which is the newest.
Could use semantic, but I'm almost never breaking compatibility with previous data formats, so it'd be something like version 1.1.9001 :)

I thought of using "number of commits" as a version number, since I do not rewrite history or squash.
But that's still less than Build 380 (or 400 for that matter).

I was thinking of using git log | wc -l (number of lines in commit history) as a version number, it will be larger than any other number, and never decrease.

What do you think of that hack ?

Oh, I could also use ISO date as a version number?
2020-04-06

[AMDmi3]

GIT sha's are nice, but one can't easily tell which is the newest

Precisely, these should never be used as or in version numbers.

Could use semantic, but I'm almost never breaking compatibility with previous data formats, so it'd be something like version 1.1.9001 :)

That's OK and you should not worry about it. Btw, you increase minor (not pach) on new features, so it's more likely to be something like 1.23.1. And note that you've used the word almost, that's exactly what major version is for, even if it stays 1 most of the time.

I thought of using "number of commits" as a version number, since I do not rewrite history or squash.
But that's still less than Build 380 (or 400 for that matter).

You could just start semver at 400.0.1 or 400.1.0.

I was thinking of using git log | wc -l (number of lines in commit history) as a version number, it will be larger than any other number, and never decrease.

I'd avoid this because git log format may not be guaranteed to be stable, non-contiguous versions are confusing, and that's a strange thing to tie versions to in general. You may also need to branch from older point in commit history at some point, e.g. to release a hotfix for a latest release, while having more commits on master you're not ready to release yet.

Oh, I could also use ISO date as a version number?

I'd avoid this as some repositories package git snapshots and use dates as versions and there's no way to tell such snapshot from official release version in this case. Also dates have unfortunate psychological side effect of users treating dates with non-current year as outdated or abandoned projects.

Summarizing, I'd suggest semver as most bulletproof, standard and common, with usual rules (bump major for breaking changes, or just reserve it for some force major cases, bump minor for new features, bump patch for other smaller changes such as bugfixes), optionally starting at 400 or so to make it higher than any currently used versions.