Let's talk version numbers

[adrianinsaval]

@wmayer @yorik @uwestoehr can somebody explain how do the version numbers in FreeCAD work? Why is it that we have 0.19 but no 0.19.0 and then we have 0.19.1? Here it says FREECAD_VERSION_PATCH is supposed to be used to set the third level number but it seems it's not being used, it's set to 0 but that doesn't appear in the version info you'll notice it is set to 0 for our 0.19.4 release.

Also what is the difference between PACKAGE_VERSION and FREECAD_VERSION and all their variants, why is there a useless PACKAGE_VERSION_NAME?

Can we get to an agreement on how the version numbers should be set?

I propose that the stable release of 0.20 be 0.20.0.xxxxx where xxxxx is the commit count, for that the FREECAD_VERSION_PATCH should actually get used and reported instead of ignored and then for future point release we'll make a commit changing FREECAD_VERSION_PATCH and that commit will be tagged as the point release.

[uwestoehr]

I propose that the stable release of 0.20 be 0.20.0.xxxxx where xxxxx is the commit count,

Let's keep it simple. 0.20.0 is OK. Only developers care about the commit number but our target audience for a stable release are average users. Devs/Pro users often work already with their own builds. And by checking the tag in Git you also get the commit number when the tag was set.

[adrianinsaval]

Ok so we keep commit count only for the dev builds, sounds good. We need the software to actually report it's version like that though, with the stable releases that are out now the version numbers are a mess, some of the builds report like 0.19.xxxxx+xxxx or other weird numbers like that, the Debian and Ubuntu builds just reports 0.19 or 0.20, the flatpak has totally wrong numbers because it uses a shallow clone (I'm working on fixing that).

[adrianinsaval]

The problem with not including commit count on the stable releases is that it might be hard to differentiate them from the Debian/Ubuntu builds that I mention which don't include the count even if they are dev builds. Note the I'm mostly talking about the version info reported by the software. The tags and announcements obviously don't need to mention commit count.

Another option is to use even and uneven numbers to differentiate development and stable releases or start using again the dev suffix that is also mentioned in the cmakelists.txt but seems unused.

[onekk]

The problem with not including commit count on the stable releases is that it might be hard to differentiate them from the Debian/Ubuntu builds that I mention which don't include the count even if they are dev builds. Note the I'm mostly talking about the version info reported by the software. The tags and announcements obviously don't need to mention commit count.

Another option is to use even and uneven numbers to differentiate development and stable releases or start using again the dev suffix that is also mentioned in the cmakelists.txt but seems unused.

Ok for simplicity, but probably some indication somewhere about the "build number" that may be even a "Build date" will be useful, at least to point out regression when an user is reporting a bug.

OK that if FC is released using subversion, like 0.19, 0.19.1, 0.19.2, 0.19.3 and so on, probably it will suffice, it is left to developers take track of what is released and what "git version number" is related to a "point release" for every OS.

Dev versions is another different thing.

Regards

Carlo D.

[yorik]

Having 0.20 and later, if a bugfix relase is made, 0.20.1, 0.20.2... is not uncommon, Blender does that too. But indeed it causes problems with package managers on some distros, because then it conflicts with, for ex, the date or a git hash that is used in the version number, ex: 0.20.15fa5e < 0.20.2...

[adrianinsaval]

Yes that conflict is part of the issue, but even 0.19.4 doesn't report itself as 0.19.4 which can be problematic for helpers, here the freecad info from the flatpak:

Code: Select all

OS: KDE Flatpak runtime (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.14555 (Git shallow)
Build type: Release
Branch: (HEAD detached at 0.19.4)
Hash: 476ecf091941bead59b14e44afa6064d5a66afa3
Python version: 3.9.9
Qt version: 5.15.3
Coin version: 4.0.0
OCC version: 7.5.1
Locale: English/United Kingdom (en_GB)

you get to know it's 0.19.4 from the branch info though but that should be in the version field

[wmayer]

Here it says FREECAD_VERSION_PATCH is supposed to be used to set the third level number but it seems it's not being used, it's set to 0 but that doesn't appear in the version info you'll notice it is set to 0 for our 0.19.4 release.

See git commit 4a6656d979aee4aaa7. This information appears for the executable on Windows in the version information tab.

why is there a useless PACKAGE_VERSION_NAME

JRiegel once has added it that is supposed to be a code name like we have for the Ubuntu versions. But we never changed it. So, we can also remove it again.

[yorik]

JRiegel once has added it that is supposed to be a code name like we have for the Ubuntu versions. But we never changed it. So, we can also remove it again.

I remember seeing somewhere in the code that FreeCAD actually already had such a name

[adrianinsaval]

See git commit 4a6656d979aee4aaa7. This information appears for the executable on Windows in the version information tab.

what file needs to be edited for linux and macOS? also there is a freecad.rc file that has different content than freecad.rc.cmake which is kinda confusing, I'm assuming the .cmake one is the one that counts is that right?

edit: I misunderstood it, it's displayed in the properties dialog of the .exe, the about dialog inside freecad still reports only MAJOR.MINOR.COMMITCOUNT, no suffix no patch, and the commit count is showed as a sum for some versions.

JRiegel once has added it that is supposed to be a code name like we have for the Ubuntu versions. But we never changed it. So, we can also remove it again.

Just in case anyone is getting any funny idea, no codenames please, terrible way of identifying a version. Also it's a little funny that most versions have codename vulkan and freecad doesn't support vulkan (not directly anyways) I assume it predates the graphics api?