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

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

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

Post by realthunder »

aapo wrote: Wed Feb 17, 2021 8:14 pm Let's just "do the Google", and drop the zero, and call them FreeCAD 18 and FreeCad 19, respectively. Is that number Big enough for everyone? Google Chrome is at version 0.89 at the moment, but everyone is Happy when they call it "Chrome 89". Just kidding! :lol:
Wow, I didn't know this thread is still so popular! Anyway, I like this idea. FreeCAD 19 feels way better than 0.19.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

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

Post by uwestoehr »

I propose to name it after the year, so "FreeCAD 2022" for the release that comes out in 2022. Then the numbering discussions are all over.
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

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

Post by kkremitzki »

Except I don't think aiming to release only once a year is a good thing...
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

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

Post by uwestoehr »

kkremitzki wrote: Sat Mar 13, 2021 1:58 am Except I don't think aiming to release only once a year is a good thing...
But twice as better than the 2 years between FC 0.18 and 0.19 :lol:
User avatar
chennes
Veteran
Posts: 3876
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

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

Post by chennes »

kkremitzki wrote: Sat Mar 13, 2021 1:58 am Except I don't think aiming to release only once a year is a good thing...
Could go with the Ubuntu (and I'm sure many others) strategy of Year.Month.

As an aside: this discussion has been really interesting to read, there are so many ideas and points of view. It makes me question whether having a version number is necessary at all. Then again, I am usually running on version ThisMorning.HEAD so my opinion is probably suspect here :) .
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

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

Post by kkremitzki »

uwestoehr wrote: Sat Mar 13, 2021 2:26 am
kkremitzki wrote: Sat Mar 13, 2021 1:58 am Except I don't think aiming to release only once a year is a good thing...
But twice as better than the 2 years between FC 0.18 and 0.19 :lol:
But that's kind of my point, though, schedule slippage is a fact of life. If your scope is calibrated for years, what's another one? If version 2021 comes out in 2022, it'll likely lead to confusion (is this really the latest version? It's not $current_year...) or be a vector for fear, uncertainty, and doubt about the project health. The flip side of the coin is risking quality to hit a fixed annual release deadline, but that seems the only reasonable way with that version scheme.

As far as extending the yearly version number scheme with months and dates, e.g. v21.3.12... in order to move to that scheme, a decision has to be made about how bugfix versions will be handled. You could just tack on a 4th position to the dotted decimal, or add a date of the bugfix commit. I don't really like either, because date.date.date.some_integer feels wrong on some level, and date.date.date.another_potentially_long_date is unwieldy. Another option is simply not having bugfix releases, only the most recent stable as the only supported version, with a development version being some number of commits ahead of that.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
LarryWoestman
Posts: 98
Joined: Fri Oct 09, 2020 4:56 pm
Location: Oregon, USA

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

Post by LarryWoestman »

A part of the discussion that is mostly missing is "Why have releases at all?". What people mean by "release" may also differ quite a bit.

For the "core" developers a release is useful for about an hour :-) Then there is the next bug fix or new code and the release isn't very interesting any more.

For the "other" developers a release is a stable platform that they can build and test their code on. It might be interesting until the first bug fix that affects their code or the first piece of new "core" code that they want to take advantage of. Then they release the next version of their code and you end up with something of a hybrid situation where the core may be stable but some of the "other stuff" (workbenches and macros in the FreeCAD context) have changed.

Since FreeCAD depends on lots of code from other places there is extra complexity about when to use a new version of someone else's code, as well. Some of the "other code" might be critical to FreeCAD's functionality and some of it might be used only in a given workbench or macro.

Non-developers tend to want "stability", so that they can create their content and be able to read and write their old content. If they want change at all, it is usually just bug fixes that don't make their old work invalid. They might be willing to change if enough new capabilities come along, but it is a big issue in many cases. There is a significant investment in learning how to use the current version of the program, and there is significant resistance to having to re-learn things when they change.

The same person may want different things from the release process at different times, depending on why they are using the program.

In my experience there are three types of releases (at least).

There is the "big impact" release where everything might change, usually driven by some big block of new functionality. There is usually an attempt to be able to read old files and content, but the user interface, API's, and/or the file formats might change.

There is the "incremental addition" release where most of the product doesn't change, but an additional block of new functionality is added. As long as you don't use the new functionality you don't have to learn anything new.

There is the "bug fix" release where the only thing that is supposed to change is that one or more bugs have been fixed.

Then there are the "not good" types of releases where bug fixes and other changes are mixed together without a sufficient amount of new capabilities that makes it worth while for everyone to re-learn all of the changes.

A common pattern for release numbering is "major.minor" or "major.medium.minor" where the major number changes any time the file formats or API's change, the medium changes when something incremental is added but the file formats and API's are still the same, and the minor number changes when one or more bugs are fixed.

It might be useful to describe what kind of changes are appropriate for what kind of "releases" so we can make sure we are talking about the same thing.
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb »

I tried to find out what the others have as version naming scheme.

SolidWorks uses the year, plus a service pack number, currently "2021 SP2".

Catia uses a version number which has made it in 40 years from V1 to V6 plus a revision number, sometimes named after the year, sometimes susequently. It's not quite clear to me which version is the latest, "v6 R20" from 2013 or "v5-6 R2019 (R29)" from 2019
Catia development started in 1967 and came to market 1977.

Creo (formerly Pro/Engineer) restarted several times with different naming schemes. It started with sequential numbers 1, 2, 3, ... and reached 19 in 1999. Then they switched to 2000, 2000i, 2000i², 2001, followed by Wildfire 1.0, Wildfire 2.0, ... followed after renaming to PTC/Creo by 1.0, 2.0, ...
Pro/Engineer came out in 1988

Another interesting question is: what did they call their version 1.0. I couldn't find much on this
When SolidWorks came out in 1995 it had already basic assemblies included. (https://blog.alignex.com/the-history-of-solidworks)
Pro/Engineer claims to have been in 1988 the first to market being parametric and feature based.

-----------------

Following vocx arguments it boild down tothe extreme "we can name FreeCAD 1.0 if it is on par with other major systems". The other extreme is "go for 1.0 now". And we have something in between such as "If Assembly is included and Topological naming issues are solved we can name it 1.0".

The advantage of naming FreeCAD 1.0 is, that it would be taken more serious, especially by companies and perhaps universities. This doesn't really have a counterpart in remaining below 1.0, because every company taking software into account would first check, if it satisfies its needs, and they would not come back whining that they had expected an Assembly workbench, because its version number is 1.x.
But in the meantime I am not so sure if having more and more users is really better and better. So let's go out and make FreeCAD better and better, and give it any name you want.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
heda
Veteran
Posts: 1348
Joined: Sat Dec 12, 2015 5:49 pm

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

Post by heda »

makes me smile,
an fc bikeshedding moment...

bikeshedding is important for community building.

in light of that (fully aware of the self-irony on display here, can't resist the allure of bikeshedding this time around :-)),
here are my 2 cents:

fc, since it is open source and free will always pick up new users by "word of mouth",
where the vast www is probably the real voice to be reckoned with,
unless we are talking about a multi-user company that needs a real counterpart to be interested to begin with.

you have to have heard about fc through the grapevine to even know about it.
once you hear about something new, unless it comes from a very trusted source,
it is fair to assume that people make some initial investigations if it seems to be something worth trying.

how do most people get the "latest version"? they simply go to the download page
and pick up what is there called the latest version (evident by several threads on the forum).

I would take the view that it does not matter what the version scheme is,
people will download the latest no matter what it is called,
and keep track of how that evolves by themselves.

when it comes to developers and helpers, they are already in the know anyway,
so for that part one could see this as something reflecting personal opinion more than anything else.
could that be the main reason why it is so hard to get agreement on a version scheme?

not to forget that they are likely testers as well, so in practice I imagine that they
seldom work with the release versions other than checking some specifics.
or they are like me (driveby helper), lazy and don't bother so much if the latest and greatest is used,
as long as it does not hinder the actual work being done - and for me v0.18 has been plenty good, I have never felt limited in ability to get what I want done on v0.18 - it basically always boils down to me initially not knowing how to get it done.

so, what is the actual wish in changing version scheme?
it seems like the core argumentation is that it will be a more "modern" version scheme,
or that prospect users would feel more comfortable using fc if the version number was higher,
or that to get penetration within companies it needs to be > 1.

the last first...

imho what companies are looking for is stability and support, i.e. to know that if you throw
money at the problem it will go away. this fc does not do (and in my opinion should not ever),
for this simple reason, imho the version scheme has to play a truly secondary role in company adaption. (I guess the only practical model here is local reach, i.e. support companies acting locally not directly affiliated with fc, other than that they hopefully contribute when they do improvements for their customers)

then we have the comfort of using, it seems to me that new users for the last year or so have proudly reported that they are using the "latest released", ending up perplexed when told that they actually should be using the "pre-release" that they can pick up at a page which for most is not easily found (and then they have to be instructed which version to choose).
albeit most of them seems to appreciate the v0.19_pre once the initial confusion of using a dev version has worn off.

I choose to take the view that they are much more puzzled over how to actually use fc at all,
relative to what the name of the version they are using is and what that means.

the more modern versions scheme, like for example dates which some are using on format YY.MM, or YY.MM.DD.
a scheme like that is at least for me more complicated, I don't see much point in forcing everyone to remember more than one single number,
which is easily done today, I think of the actual version to use as "latest 18" (like v0.18.4), or "latest 19" (v0.19.1).


after all this bikeshedding, I have landed in that the current version scheme is actually really good all things considered.

- there is a 0. because it does not have functionality that some wishes it would
- 0.xx allows for everyone to know what the used version is
- 0.xx.y is well understood as an improved version of 0.xx
- as pointed out by an earlier poster, 0.xx easily becomes just the xx in daily talk,
and I don't see any harm in that, rather it just makes things simple.

so, for me it in the end boils down to what version is referred to as "latest released",
not what that version scheme looks like, well apart from that the less numbers the better it is,
and just ticking digits is timeless, which I think suits a project that has the motto "it is done when it is done".

could a switch of version scheme actually be counter productive? changing name or version scheme can also signal for a need to "sell it as new" when nothing really has changed apart from some superficial cosmetics, or worse new functions that no one actually uses.

imho, a new release of fc with a tick in digit has brought real improvements to the table,
that is what fc so far has taught the old dogs like me, i.e. every release is worthwhile updating to - that I wish will stay for a long time to come,
changing version scheme will then be erasing the easy to understand history of releases.
User avatar
Aleks
Posts: 309
Joined: Sun Mar 08, 2020 5:27 pm
Location: Bonn, Germany
Contact:

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

Post by Aleks »

I think the release naming scheme is fine.
FreeCAD als Maschinenbauer in die Konstruktion und Fertigung integrieren. Schulung buchen: www.alsado.de/freecad-schulungen
Post Reply