Dear Mod creators. (re: mod versioning)

[Fengist]

In an effort to expand Kerbaltopia.com, I have recently taken upon the daunting project of parsing every single .ckan file into a MySQL database which already contains API data from Kerbalstuff.com. While perusing through this data and trying to determine which version of a particular mod is the most current, I ran into a snag.

You see, PHP has this wonderful command called version_compare. It's pretty smart actually and when sorting through over 3,000 versions (something I am NOT going to do manually) it's a real time saver. I even read through CKAN's mind boggling explanation of how versions are supposedly ordered in their scheme of things and neither manages to completely deal with human versioning logic. For example, the below list of mod versions are just few of the truly bizarre ones I've come across.

Deprecated

alpha_7.0

Rev_4

Rev_5

Rev_6

0.14.1.1.oops

pre-alpha-04

pre-alpha-06

0.000001

ksp1.0_release1

1.2.0_-_KSP_1.0_Update

2015-05-20

yadaya

test_for_license_validation

whatever

Version_3D_changes

Verision_Preview_3C_available

0

0.0

0.0.0

Now just assume that machine code had to somehow determine which of those is the most recent version, Then consider that CKAN doesn't have an 'uploaded date' field and all of the .ckan files have the same date when unzipped. You see my problem?

here's a real fun one.

v1.0

1.01

If I understand CKAN correctly, v1.0 is a newer version than 1.01. Version_compare gives the opposite results. And yes, I've seen mods use both schemes in their versions of the same mod.

Now mind you, the vast majority of you modders have got the art of versions down pat. And your logic is appreciated. Some of you however... wait, I have ammunition around here somewhere.

Edited May 25, 2015 by Fengist

[Kerbas_ad_astra]

Speaking of version numbers, it would be good to bring up Semantic Versioning. The short version:

1. Major version number (X.y.z) gets incremented when making compatibility-breaking changes (e.g. changing part names or sizes, removing or renaming interface methods)

2. Minor version number (x.Y.z) gets incremented when adding functionality in backwards-compatible ways (e.g. new parts, new methods)

3. Patch number (x.y.Z) gets incremented for bugfixes that don't add anything new.

We mostly follow this pattern intuitively, but it would help to do so consciously.

[Fengist]

Speaking of version numbers, it would be good to bring up Semantic Versioning. The short version:

1. Major version number (X.y.z) gets incremented when making compatibility-breaking changes (e.g. changing part names or sizes, removing or renaming interface methods)

2. Minor version number (x.Y.z) gets incremented when adding functionality in backwards-compatible ways (e.g. new parts, new methods)

3. Patch number (x.y.Z) gets incremented for bugfixes that don't add anything new.

We mostly follow this pattern intuitively, but it would help to do so consciously.

As someone who writes software, I understand that at times it's nice to be able to add a 'note' to your version. But somewhere in the details there needs to be some solid logic because code doesn't understand the difference between 'beta' and 'alpha'. At present, there's 2 major collection points for mods, CKAN and Kerbalstuff (we won't even discuss Curse). If they don't enforce logical versioning, it won't happen.

[Alshain]

This sounds like a CKAN issue more than the mod developers issue. All software developers have their own version of numbering, even when using semantic versioning there are distinct flavors and differences in usage. For example, .NET uses Major.Minor.Build.Revision and since KSP mods are in C# which may or may not be done in .NET, there is nothing wrong with that either.

There is just no way you are going to get every mod developer to be uniform in this matter I'm afraid. CKAN should be a little smarter, in software it isn't hard to strip alpha charaters from a version number, so the "v" could be removed before comparison and if any comparison returns 1.0 as being greater than 1.01 then it has serious issues.

[Kerbas_ad_astra]

As someone who writes software, I understand that at times it's nice to be able to add a 'note' to your version. But somewhere in the details there needs to be some solid logic because code doesn't understand the difference between 'beta' and 'alpha'. At present, there's 2 major collection points for mods, CKAN and Kerbalstuff (we won't even discuss Curse). If they don't enforce logical versioning, it won't happen.

Semantic versioning includes a provision to put prerelease information after a minus sign (e.g. 1.0.2-alpha), and/or "build metadata" after a plus sign (1.0.2+build:8802). I didn't include that in the "short version" because it's not the meat of the idea, but it's there. (There's a very nice drill-down of precedence order under point 11, about halfway down the page.)

[Fengist]

This sounds like a CKAN issue more than the mod developers issue. All software developers have their own version of numbering, even when using semantic versioning there are distinct flavors and differences in usage. For example, .NET uses Major.Minor.Build.Revision and since KSP mods are in C# which may or may not be done in .NET, there is nothing wrong with that either.

There is just no way you are going to get every mod developer to be uniform in this matter I'm afraid. CKAN should be a little smarter, in software it isn't hard to strip alpha charaters from a version number, so the "v" could be removed before comparison and if any comparison returns 1.0 as being greater than 1.01 then it has serious issues.

It's not just CKAN. Half of those came from CKAN, the other half from Kerbalstuff. The best I can do for now is a 'humanized' sorting method (strnatcmp) built into PHP. I already know that some mods are going to have the wrong version listed. For example, I found this in a single mod's .ckan files.

v.13.0

v.14.0

v.15.0

v13.1

All of that mods versions are prefaced with a dot except one. I know damn well the mod creator intended for .15 to be the latest release but, in 13.1 he forgot to place the dot. The only thing I can do, without having to manually sort through the 5,609 mod versions I now have in the database... is to hope for the best.

[sarbian]

Do you really think that those that use "truly bizarre" (your words) version scheme will care ?

And "2015-05-20" is a perfectly good version scheme. The fields are in the most to least important order and if works fine as long as you don't do 2 version a day.

[Kerbas_ad_astra]

And "2015-05-20" is a perfectly good version scheme. The fields are in the most to least important order and if works fine as long as you don't do 2 version a day.

The problem with date-based versioning is that it gives me no information for compatibility -- if I use version 2015-05-20, and then 2015-05-21 is released, will upgrading break anything? Semantic versioning takes out the guesswork -- a system that relies on ModuleFoo v. 1.2.3 will work fine with 1.2.4, or even 1.3.0, but not 2.anything.

[m4v]

I don't think you can compel everybody to switch to an unified scheme, version numbers are arbitrary and doesn't need to be logical if the author believes it to be useful.

[Fengist]

I don't think you can compel everybody to switch to an unified scheme, version numbers are arbitrary and doesn't need to be logical if the author believes it to be useful.

Then there needs to be another logical method of determining the most current version. CKAN doesn't offer an upload date in their schema making version numbers the only thing left. And with over 900 mods in my database, I'll be damned if I'm going to write separate function for every mod that doesn't use a standardized versioning system.

[Guest]

Then there needs to be another logical method of determining the most current version. CKAN doesn't offer an upload date in their schema making version numbers the only thing left. And with over 900 mods in my database, I'll be damned if I'm going to write separate function for every mod that doesn't use a standardized versioning system.

Good luck and godspeed. o7