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

[Joel_graff]

I remember reading somewhere that using a year-based versioning scheme could create issues for Debian packaging or something... No idea why / how, but it's something to consider.

[kkremitzki]

How often does one really need to say, version X was this long ago? All that seems to matter to me is to know the current version, and to be able to say whether a version is older than current. 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. It also keeps our tie to yearly releases, which IMO we should view as a historical coincidence... having huge gaps of time between releases doesn't help us get any better at making releases.

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

It seems the consensus to 1 is 'yes'. The arguments for 2 are strong--not having a 1.0 release is like not having a graduation ceremony. Deciding on 3 can IMO be deferred after we drop the leading 0 and after we have a 1.0 release--it's a separate issue.

Also, I don't think a year.date versioning system would cause any Debian packaging problems, except that if we switch to it we can't easily switch back, which seems unlikely anyway.

[Mark Szlazak]

How often does one really need to say, version X was this long ago? All that seems to matter to me is to know the current version, and to be able to say whether a version is older than current. 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. It also keeps our tie to yearly releases, which IMO we should view as a historical coincidence... having huge gaps of time between releases doesn't help us get any better at making releases.

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

It seems the consensus to 1 is 'yes'. The arguments for 2 are strong--not having a 1.0 release is like not having a graduation ceremony. Deciding on 3 can IMO be deferred after we drop the leading 0 and after we have a 1.0 release--it's a separate issue.

Also, I don't think a year.date versioning system would cause any Debian packaging problems, except that if we switch to it we can't easily switch back, which seems unlikely anyway.

I do not understand how 1.0 or 2.0 tells me whether i am using a current version not??

[Zolko]

I do not understand how 1.0 or 2.0 tells me whether i am using a current version not??

you're really a helpless lot: 1.0 is cool, and 2.0 is futuristic. geeez ... didn't you learn anything in engineering school ?

[Zolko]

friendly and constructive manner until Zolko and you joined it

sure ... a nice scape-goat you have here....

[Joel_graff]

you're really a helpless lot: 1.0 is cool, and 2.0 is futuristic. geeez ... didn't you learn anything in engineering school ?

I'm really not at all sure what that's supposed to mean.

The value of moving to version 1.0 is primarily for public relations. It signals to others that our project is one that has matured and has considerable value to it's users - and there's plenty of evidence to be found both here and outside our community that demonstrates these things are true.

In the end, though, it's really only a number. It has no intrinsic value beyond indicating a progression in development.

[Zolko]

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.

I don't know about Jürgen, but that seems quite logical today.

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

[bernd]

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

yes, yes, yes, jm2c

[kkremitzki]

I do not understand how 1.0 or 2.0 tells me whether i am using a current version not??

Strictly speaking a year.month version doesn't tell you if it's current or not, either, just if it's recent.

yes, yes, yes, jm2c

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

[Mark Szlazak]

I do not understand how 1.0 or 2.0 tells me whether i am using a current version not??

Strictly speaking a year.month version doesn't tell you if it's current or not, either, just if it's recent.

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