There can be two labelling systems in use, to confuse matters more. The alpha, etc labels could be for the user announcements. A release number like 5.99 makes sure that 6.0.0 collates higher than any preceeding dev releases for the sake of update managers. A .99 system is not unkown in the FOSS world. Some FOSS just use a monotonically increasing build number.
As far as I know this version numbering is quite common, and has been so for 30+ years.
There even used to be a fourth number in some numbering system, and that was used for each build. I think itās mainly from what world you come, and this numbersing system is more often used by programmers and not always exposed to end users.
For example, a simple search:
https://html.duckduckgo.com/html?q=program+version+numbering
Gives this as itās fourth link:
Which states:
Best practices for versioning my software
New projects start at version 0.1.0
You are starting with a set of features, not bug fixes.
Increment the minor version for each subsequent release.
Start versioning at 1.0.0 if:
Your software is already used in production.
Other users depend on your software and care when the API changes.
You are worrying about backwards compatibility.
The initial development phase is represented by MAJOR version 0
Make as many breaking changes as you want before v1.0.0
Once you have released v1.0.0, API adjustments or other breaking changes are not acceptable without a new MAJOR version change.
If you are adding new features without breaking the existing API or functionality, increment the MINOR number.
If you are fixing bugs, increment the PATCH number.
Thank you for providing these links.
The 4th link provided helpfully describes Version numbering with MAJOR, MINOR, and PATCH numbers in the configuration of X.Y.Z MAJOR.MINOR,PATCH. I agree with you that this is exactly how KiCad tracks itās PUBLIC release versions. I believe the pivot point here is DEVELOPMENT releases.
To my knowledge, KiCad does not make use of alpha, beta, and RC nomenclature. Development versions switch from 5.0 to 5.99 a nanosecond after the official release of 5.0 and then hold at 5.99 (plus a bunch of numbers) as the version number for 12-24 months. I believe this is unique in the industry. This choice may be a point of perpetual confusion for new users.
I am not requesting/persuading/demanding a change. I am only suggesting one possible explanation for why customer confusion persists despite scary warnings. User error is of course another.
I have no problem with the .99 setup. You would only switch from 5.1 to 5.99 if you have both production and dev repos registered with your package manager, in which case .99 wins out. That would be a user error, you should not have both production and dev repos active at the same time on a machine.
The problem that a dev repo user faces is that 5.99 jumps to 6.99 on release of 6.0.0. Normally only dev testers would be affected and this would be par for the course, but 5.99 was touted as the one to use by users impatient to have a taste of 6.
It may be a good idea to add text strings such as āalfaā or ābetaā to the x.99 version.
This would give beginning users an extra hint even if they get KiCad from some mirror site.
1 Like
The problem is even ā7.0-alphaā may be considered by some people as āstableā. The indie sector of the gaming industry has done itās absolute best destroying the word āalphaā in the last few years when it comes to release state.
Really the best solution would be go full commando without a version number in my book, just commit hashes, heh.
1 Like
Another method is to not use āKiCadā at all for the nigtlies, but only a codename.
But in the end it probably does not matter much as long as it does not become a burden on the developers. On this user forum there are plenty of people who can nudge beginners in the right direction, and even beginners have responsibility for their own actions. If they act without thinking, then the is no scheme that can prevent them from doing so.
For the long run it would be nice if KiCad was able to give a warning about an unknown file format, and then ādo itās bestā to interpret it, and then for example ignore all the S-expressions it does not understand and dump them in a file. This is under the assumption that itās better to repair a damaged ābackportā of a KiCad project, then KiCad bluntly refusing to open it at all.
1 Like
We had 5.99 at alpha and then beta level, jumping to 6.99 at what is strictly experimental when 6.0.0 - really a beta came out. It takes a point release or two for each KiCad major release to hit genuine stability
For the long run it would be nice if KiCad was able to give a warning about an unknown file format, and then ādo itās bestā to interpret it, and then for example ignore all the S-expressions it does not understand and dump them in a file. This is under the assumption that itās better to repair a damaged ābackportā of a KiCad project, then KiCad bluntly refusing to open it at all.
As someone who deals with constantly changing API formats, I agree wholeheartedly with this suggestion. Parse what you can. Warn when you canāt make sense of it. Ignore the rest. Throw a caution on version mismatches. Donāt refuse to even try.
I would strongly advise NOT to do that. Let is refuse. All sorts of unexpected behaviour can come from this. Software should be able to rely on stuff being on the places it expects so.
Last thing you want is all kinds of bug reports because the unexpected behaviour.
Please let programmers program, not do this kind of wasteful stuff.
3 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.