name FreeCAD 0.91 instead of 0.20, means version after 0.19 could be 0.91

[kkremitzki]

Yes that is what i said. Which means it is more information than version numbers like 1.0, etc.

You said current, which is not the same thing as recent.

[Joel_graff]

Also, there are actually several issues being discussed here:
1. should we drop the leading 0 in the version to communicate FreeCAD's maturity (and stop communicating its immaturity)
2. should we have a 1.0 release to communicate FreeCAD's readiness for wide usage
3. should we use a major.minor.patch or year.date versioning system

Hmmm... some of the above.

I like the last two digits of the year best. And I kinda like the idea of adopting an ubuntu style of versioning.

I'd vote for year.month.patch.

Month could be optional, and the year could be 2 or 4 digits, so any of the following make sense to me:

19.xxx, 19.04.xxx, 2019.xxx, 2019.04.xxx
(xxx = patch number)

[wmayer]

so... how about App::Link ? Is this the goal for v0.19 ? (or any next version)

Yes, that's the plan.

[bernd]

... Your third yes is in response to a either/or question.

3. should we use a major.minor.patch

yes

[bernd]

so... how about App::Link ? Is this the goal for v0.19 ? (or any next version)

Yes, that's the plan.

[bejant]

Also, there are actually several issues being discussed here:
1. should we drop the leading 0 in the version to communicate FreeCAD's maturity (and stop communicating its immaturity)
2. should we have a 1.0 release to communicate FreeCAD's readiness for wide usage
3. should we use a major.minor.patch or year.date versioning system

A1. Again I'd say yes, conditionally, after topological naming has been implemented and proven reliable. (I've included my opinion about including Assembly in FreeCAD version 1.0 toward the end of this post).

A2. If the FreeCAD release numbering system is going to be changed from 0.xx.commit to 1.0 or 1.0.commit, I think that it would be confusing to the general public to then change again to a yyyy.mm or yy.mm.commit release numbering system. But I can surely understand that people would want to have 1.0 as a celebratory release version.

A3. I don't think that including the mm (two-digit month abbreviation) in what would be a yyyy.mm release numbering scheme adds much worthwhile information, unless FreeCAD development becomes so rapid that there might be more than one "stable" release per year. Until that happens, to me it seems that "FreeCAD 2019" or "FreeCAD 2020" would work well and be appropriate. I'm becoming fonder of the "FreeCAD YYYY" suggestion. I see it as a corollary to "It's Done When It's Done": similarly FreeCAD 2019, FreeCAD 2020, and like numbered releases suggest that the FreeCAD release simply "Is What It Is".
Again this is only my 2 cents worth, and I don't have very strong opinions about the numbering scheme. I'm simply offering my suggestions because I care about FreeCAD.

And seriously what else do you expect from me? I have to check the majority of PRs, fix bugs listed in our bug tracker, make sure that FreeCAD compiles on a wide range of different platforms with different versions of libraries, participate on several development discussion, help newcomers to get their things done who use the FreeCAD API, look through the results of code checkers regularly offered by saso to improve code quality, ... while for several years I have nearly no time any more to implement the stuff that I am interested in.

Thank you, Werner, for all the work you do, and have already done. Unfortunately no matter what, or how much, you contribute there will always be some people who aren't happy about it, will be critical, and so on.

Just to post before the topic gets locked:
I like the 0.xx numbering convention FreeCAD has been using, and think a 1.0 release could wait until after Topological Naming has been implemented and proven successful...

As far as I remember from discussions with Jürgen the plan to switch to version 1.0 was when the most important issues are solved:
it's the topological naming as you said and the assembly workbench.

My opinion is that Assembly isn't so important to have in the first 1.0 or non 0.xx release, in part because people have already been creating assemblies for years without having had an Assembly WB. FreeCAD also has Placement, the Edit > Alignment tool, and the Draft WB > Move tool, so at least some rudimentary Assembly capability exists.

[Mark Szlazak]

Also, there are actually several issues being discussed here:
1. should we drop the leading 0 in the version to communicate FreeCAD's maturity (and stop communicating its immaturity)
2. should we have a 1.0 release to communicate FreeCAD's readiness for wide usage
3. should we use a major.minor.patch or year.date versioning system

A1. Again I'd say yes, conditionally, after topological naming has been implemented and proven reliable. (I've included my opinion about including Assembly in FreeCAD version 1.0 toward the end of this post).

A2. If the FreeCAD release numbering system is going to be changed from 0.xx.commit to 1.0 or 1.0.commit, I think that it would be confusing to the general public to then change again to a yyyy.mm or yy.mm.commit release numbering system. But I can surely understand that people would want to have 1.0 as a celebratory release version.

A3. I don't think that including the mm (two-digit month abbreviation) in what would be a yyyy.mm release numbering scheme adds much worthwhile information, unless FreeCAD development becomes so rapid that there might be more than one "stable" release per year. Until that happens, to me it seems that "FreeCAD 2019" or "FreeCAD 2020" would work well and be appropriate. I'm becoming fonder of the "FreeCAD YYYY" suggestion. I see it as a corollary to "It's Done When It's Done": similarly FreeCAD 2019, FreeCAD 2020, and like numbered releases suggest that the FreeCAD release simply "Is What It Is".
Again this is only my 2 cents worth, and I don't have very strong opinions about the numbering scheme. I'm simply offering my suggestions because I care about FreeCAD.

And seriously what else do you expect from me? I have to check the majority of PRs, fix bugs listed in our bug tracker, make sure that FreeCAD compiles on a wide range of different platforms with different versions of libraries, participate on several development discussion, help newcomers to get their things done who use the FreeCAD API, look through the results of code checkers regularly offered by saso to improve code quality, ... while for several years I have nearly no time any more to implement the stuff that I am interested in.

Thank you, Werner, for all the work you do, and have already done. Unfortunately no matter what, or how much, you contribute there will always be some people who aren't happy about it, will be critical, and so on.

Just to post before the topic gets locked:
I like the 0.xx numbering convention FreeCAD has been using, and think a 1.0 release could wait until after Topological Naming has been implemented and proven successful...

As far as I remember from discussions with Jürgen the plan to switch to version 1.0 was when the most important issues are solved:
it's the topological naming as you said and the assembly workbench.

My opinion is that Assembly isn't so important to have in the first 1.0 or non 0.xx release, in part because people have already been creating assemblies for years without having had an Assembly WB. FreeCAD also has Placement, the Edit > Alignment tool, and the Draft WB > Move tool, so at least some rudimentary Assembly capability exists.

I have no problem dropping the month part after the year but still having year (of release) gives more information to people using FreeCAD than say 1.0. Using 1.0 so that a few can momentarily celebrate over the many users that would continuely get more information on a year-based versions number schemes seems like a step backward.

[bernd]

My opinion is that Assembly isn't so important to have in the first 1.0 or non 0.xx release, in part because people have already been creating assemblies for years without having had an Assembly WB. FreeCAD also has Placement, the Edit > Alignment tool, and the Draft WB > Move tool, so at least some rudimentary Assembly capability exists.

+1

[abdullah]

I'm not a fan of year.date versioning systems because doesn't allow you to communicate the significance of the changes in a new version, just that it's newer, but dotted decimal versions can do that too.

Would it make sense to have a major for version followed by a yy.mm or it would be an abherration?

Something like: 1-19.03 or 1.19.03.

I am not sure if this is better (more information) or worst (poor cohesion by mixing traditional versioning with release date information).

[kkremitzki]

Would it make sense to have a major for version followed by a yy.mm or it would be an abherration?

Something like: 1-19.03 or 1.19.03.

I am not sure if this is better (more information) or worst (poor cohesion by mixing traditional versioning with release date information).

Hah, I'm not sure if it's any better either. Whether major.minor.patch, YY.M.patch, or any other variation, does not matter too much to me, so long as the 0 is dropped. With a topic like this it's probably something Werner/Yorik will have to decide on.