Let's talk version numbers

[onekk]

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)

This is for the Version:

That is "confusing"

Code: Select all

Build type: Release
Branch: (HEAD detached at 0.19.4)

This is the Branch: that seems to bring the "relevant" information 0.19.4


If "version number" will be "renamed" and "reference" and in Version: there will be the actual Branch info better stripped from "HEAD detached at" this could be a viable solution.

As the Version Number will be consistent and easy to note down.

for versions of dev probably something like 0.20.0.<gitnumber> should be a solution?

In code this could resemble something like Branch+gitversion


EDIT output of

Code: Select all

FreeCAD.Version()

['0', '19', '24366 (Git)', 'https://github.com/conda-forge/freecad-feedstock', '2021/12/04 21:56:30', '(HEAD detached at 0f9259c)', '0f9259cda103ae1824ac16c68ac9b4a0d54b05fc']

Some scenarion:
1) adding as third component subsubversion (0,1,2,3,4) and leaving the "24366 (Git)" as fourth component
2) leaving all like this and adding a new component last in the list with the subsubversion.
3) adding a new field at the end with the complete version number "0.19.4" as example, and manage internally the composition

Probably 2) and 3) will not break existing code if there are some concerns.

Only packagers and developers have to cope with the version number, as if git is consecutive a "wb developer" that is in need to find a point were things changed could eve use the (24366) or even the full commit number in a check to use "new features" or "different behaviour"

But I don't know how feasible is this solution.

Regards

Carlo D.

[wmayer]

what file needs to be edited for linux and macOS?

I don't think this is supported on Linux or 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?

freecad.rc.cmake is a template and when running CMake configure it creates the freecad.rc file by replacing the content of some placeholder variables. The freecad.rc file adds the version information and an icon into the executable file.

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.

We could add this information to the About dialog too but for developers this is irrelevant. When checking a bug in the code then major.minor number already gives the branch in the repository and the most important information is the commit hash value.

Also it's a little funny that most versions have codename vulkan and freecad doesn't support vulkan (not directly anyways)

It's not related to the Vulcan API as successor of OpenGL.

I assume it predates the graphics api?

Jürgen is a fan of Star Trek and that's where the name came from.

[Jee-Bee]

It's a pity that Jürgen is not around here anymore...
I can't remember if he was when i came here but i remember his signature...

Stop whining - start coding!

Someone (who less wined and code more often than me ) should take over!!

[adrianinsaval]

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.

We could add this information to the About dialog too but for developers this is irrelevant. When checking a bug in the code then major.minor number already gives the branch in the repository and the most important information is the commit hash value.

my idea is to reduce confusion among users and helpers not really developers, those who understand this stuff can look at what commit it is with the hash but for the rest some consistent numbering would be more helpful. I bring this up because I've seen confusion due to this in many places. Not too long ago we had issue were archlinux was incorrectly packaging 0.19.3 and calling it 0.19.4 and several people didn't notice even after looking at the version info in the about page, if it had said 0.19.3 it would have been immediately obvious there was an issue.

[uwestoehr]

we decided that the release tag will be

0.20.0

@yorik will or maybe already communicated this to the package maintainers

[yorik]

I don't know who to communicate this too... IMHO we first need to be clear ourselves and make sure it is labelled so everywhere (github, etc...) and also in FreeCAD itself. Note that currently FreeCAD doesn't itself provide for a third version number. In the About dialog as well as in FreeCAD.Version(), there is definition for a major and minor version number, and a git hash.

I didn't think about this earlier unfortunately, and it seems dangerous to change how FreeCAD.Version() works right now just before the release, because it might screw scripts out there that rely on it.

So I would start by correctly git-tagging, naming our own packages, and advertising i on our website... And assume that (for the time being) 0.20 == 0.20.0

[uwestoehr]

So I would start by correctly git-tagging, naming our own packages, and advertising i on our website... And assume that (for the time being) 0.20 == 0.20.0

Thanks, So I will tag the release as:

0.20

[adrianinsaval]

I interpreted yorik's words the other way around @yorik did you mean to tag as 0.20 or 0.20.0?

there is definition for a major and minor version number, and a git hash.

In Version.h.cmake a patch number is also defined but apparently only used for the windows .exe properties.

If possible I would like to have a more clear system for 0.20.1 since it's too late for 0.20, if not desirable there either, then let's discuss about the next stable version, if it's really going to be 1.0 we can forget about a third number and use the second number for this but this would mean the next stable release would be 2.0 and so on.

[uwestoehr]

I interpreted yorik's words the other way around @yorik did you mean to tag as 0.20 or 0.20.0?

0.19 was tagged as

https://github.com/FreeCAD/FreeCAD/commits/0.19

So 0.20 will use the same scheme, meaning

0.20

0.20.x are then the usual bugfix-only releases.

[yorik]

I interpreted yorik's words the other way around @yorik did you mean to tag as 0.20 or 0.20.0?

I meant using 0.20.0 everywhere we can, but it actually doesn't matter... 0.20 == 0.20.0 If that's clear, then the way it is tagged is of little importance. And yeah, actually it's a but too late for this one, because linux distros like debian will usually use their own numbering system for after the 0.20 part. But we could try to notify as many of them as possible that we'll probably have 0.20.1, 0.20.2, etc...)
@Kunda1 I think you had a list of package managers somewhere?