Let's talk version numbers
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- adrianinsaval
- Veteran
- Posts: 5551
- Joined: Thu Apr 05, 2018 5:15 pm
Let's talk version numbers
@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.
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.
Re: Let's talk version numbers
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 wrote: ↑Mon May 30, 2022 12:52 am I propose that the stable release of 0.20 be 0.20.0.xxxxx where xxxxx is the commit count,
- adrianinsaval
- Veteran
- Posts: 5551
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Let's talk version numbers
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
- Veteran
- Posts: 5551
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Let's talk version numbers
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.
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.
Re: Let's talk version numbers
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.adrianinsaval wrote: ↑Mon May 30, 2022 2:52 am 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 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.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.
Blog: https://okkmkblog.wordpress.com/
Re: Let's talk version numbers
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
- Veteran
- Posts: 5551
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Let's talk version numbers
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:
you get to know it's 0.19.4 from the branch info though but that should be in the version field
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)
Re: Let's talk version numbers
See git commit 4a6656d979aee4aaa7. This information appears for the executable on Windows in the version information tab.adrianinsaval wrote: ↑Mon May 30, 2022 12:52 am 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.
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.why is there a useless PACKAGE_VERSION_NAME
Re: Let's talk version numbers
I remember seeing somewhere in the code that FreeCAD actually already had such a name
- adrianinsaval
- Veteran
- Posts: 5551
- Joined: Thu Apr 05, 2018 5:15 pm
Re: Let's talk version numbers
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?wmayer wrote: ↑Mon May 30, 2022 8:15 am See git commit 4a6656d979aee4aaa7. This information appears for the executable on Windows in the version information tab.
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.
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?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.