Versioning considerations

[dav1312]

Abandoning the use of compilation dates for versioning

Currently Stockfish uses the compilation date to determine the version of the engine which causes multiple issues and confusion

Stockfish/src/misc.cpp

Lines 70 to 72 in 9f6bcb3

	/// Version number. If Version is left empty, then compile date in the format
	/// DD-MM-YY and show in engine_info.
	const string Version = "";

For example, the version that participated in the CCC 17 Rapid Finals was 190322 but since the engine was compiled a few days later, the version turned out to be 220322 which doesn't really "exist".

This can cause other weird situations like compiling a version from a year ago returns the same version as compiling the latest one which doesn't make any sense.

This also causes problems when multiple commits are made on the same day because you can't really identify them using the version which again renders the version rather useless
e.g. https://discord.com/channels/435943710472011776/724661489381670923/948353154976714782

This kind of versioning makes it very confusing for the average user too that might not understand what that very big number means
e.g. https://discord.com/channels/435943710472011776/733545871911813221/959838011376406649

So my idea would be to do something similar to Koivisto, increase the version on each commit, but since the mayor and minor versions already have a purpose (#3368), the idea would be to increase the patch number (e.g. 14.1 -> 14.1.1 -> 14.1.2).
This should clear all confusion regarding versions because there could not be two versions with the same number, each commit would be completely identifiable and the average user should be much more familiarized with this versioning style.

[kenta2]

I suggest the first part of version string be hardcoded and bumped after each release (e.g., "14.1"), and the build process derives a parenthesized suffix based on git commit. Another project does this in Makefile:

ifneq ("$(wildcard $(SRCDIR)/.git)","")
PKGVER := g$(shell git -C $(SRCDIR) describe --always --dirty --exclude '*')
else
PKGVER :=
endif

Thus, the complete version string might look like this: "14.1 (g012abcd)".

[dav1312]

While this would solve some of the problems it would still be rather confusing for the average user

[vondele]

I do agree that our current 'compile time date' version number is not very good.

Now alternatives should be automatic (like not having to change the version string manually or with a script on each commit), and ideally work without git being installed (like a user might just compile a .tar.gz of the sources and not have git installed).

[dav1312]

Maybe there is a way of doing it with gh actions

[vondele]

this might be, something like a hook that increments a number in a file named VERSION upon commit to master ?

[dav1312]

It should be possible with some (probably complex) bash script
The script would also need to identify if the increment should be patch, minor or mayor
Maybe adding a string next to the version that the script could read?
The string would always be "patch" and it could be changed to "minor" or "mayor"

[vondele]

This got fixed with e048d11

[dav1312]

2/3 🙃

No more confusion:

• when Stockfish is compiled a few days before the commit is done.
• when multiple commits are made on the same day.
• for the average user.

Maybe some day it will be 15.1.47-d3860f8d 😄