Standirdized Mod Version Names

[Azivegu]

While doing some work on the KSP Mod List Redux and getting geared up to start my own LP, it was frustrating to query through all the different ways people give there products version numbers.

I would think it might be a useful idea to have a standardized system to help players easily see whether or not they are up to date. I gave it some serious thought and came to the conclusion it should contain the following information:

- lets you see what KSP version it was built for

- lets you see what kind of part it is (more on that later)

- lets you see what version the file is at

- lets you see if there has been a bug fix since last update

I came up with this design: v.0.22.a.1.33.2

It can be divided up into several sections to better understand the structure.

v: Version. Acts as a control to identify the following as a version number. This could greatly help with automatic update programs.

0.22: KSP Version that the mod was built for. Why not the version it is compatible with? Because sometimes a mod isn't 100% compatible with a new KSP version. It also lets us see how well the mod has been maintained. Examples may be Bobcats rovers. Although they can work, you have to tweak the files a bit to get it to work. It also lets you know what you have to do to get it to work, like just add science node or also a PART{}.

a: Package Type Indicator. It is used to help organize what the content of the file is. It can be categorized into

-a: add-on (a package that is cored around parts (like KW and VNG),

-p: plug-ins (packages that are cored around plug-ins like Kethane, Remotetech and MechJeb),

-g: game play enhancement (packages that improve or alter game play like DR, VOID or Universe Replacer) and

-f: bug fixes or patches (packages that are only intended to repair a file that was damaged on delivery or a minor update (like only replacing a .dll))

1.33: Version of the package. Major updates change the first number while minor updates change the second 2-digit number

2: A number indicating that there has been a minor/major fix to the previous update. It is not adding any new content, but repairing possibly incurred damage. By default it should be 0. Only when a bug fix has been brought out after the version update should this be raised to 1 or more.

The biggest trouble for me was the Package Type Indicator (PTI). How do you define something like Kethane and ScanSat that has both plug-ins and parts. First I thought to just leave it out, but I realized it would be easier to read if it was included. If you had to read v.0.22.1.33.2 you would have a harder time decoding it (not that hard, but this index is supposed to be used for glance-at situations) then if it was v.0.22.a.1.33.2. The a splits it up making it smaller bits that are easier to decode.

It also helps users organize their content, but how? Like I said some packages aren't easy to categorize as plug-ins or parts. So I needed to think of a definition.

I came to the conclusion that a plug-in is a package to support a plug-in whilst an add-on is a package to support a part.

That may be a little bit cryptic, so here is my explanation:

-A package that is a plug-in has the main goal to support a plug-in. Take Kethane for example. What it is all about is fuel. Everything around it is meant to get, use and expend Kethane. The same for ScanSat. Its main goal is to map, and the tools are scanners. The reason you download it isn't for the dishes, but to map bodies.

-A package that is an add-on has the main goal to support a part. A good example is OrdanInd Telescopes. What it is all about is the telescope and it has a plug-in to help you use the telescope. One without the other and it doesn't work, but you download it so you have a telescope, not a telescope plug-in. Another example is VNG. VNG is built around parachuting with the outcome of it all the EVA parachute. The plug-in is only meant to support parachuting and nothing else (well, it does support other mods, but for the same reasons)

So what do you think? With such an active modding community, it would be nice to standardize this and make it even more easy for everybody to use. If there is something that can be done better, I would love to here it. So love it, like it or hate it, post down below as I really believe this can help a lot, even if it is such a small thing.

Some examples of mods:

Kethane: v.0.22.p.0.08.1

ScanSat: v.0.22.p.0.04.0

MechJeb: v.0.22.p.2.01.0

KDex: v.0.22.a.1.00.0

RemoteTech2: v0.22.p.1.02.7

KW Rocketry: v.022.a.2.05.5

TAC Life Support: v0.22.p.0.05.0

Kerbal Joint Reinforcement: v0.22.g.1.04.2

Graphotron 2000: v.0.20.a.0.02.1

Visual Enhancement: v0.22.g.0.05.3

Deadly Re-entry: v.022.p.4.00.0

KAS: v.0.22.p.0.04.4

Real Solar System: v.022.g.0.05.2

[rbray89]

I'm up for this. I think if we get everyone behind this it could be VERY good.

[TaranisElsu]

I cannot follow your versioning scheme because: I use Visual Studio, I compile the version number into the DLL (right click the DLL and see the Properties->Details->File version), and I automated updating the version number so that it changes every time that I build. Therefore, I am limited to four numbers in the form: 1.2.3.4. I cannot use letters and I cannot use more than four numbers. That is a restriction that Windows and Microsoft imposes on me.

My versioning scheme is currently: <major version>.<minor version>.<Julian date it was compiled>.<build number> where the Julian date is the two digit year and the day of the year (YYDDD), and the build number is the number of times that I have hit Build in Visual Studio that day.

You may have noticed that I try to encode most of the information you list above (plus last modified date) into the forum thread's subject. For example, my Life Support mod's thread says "[0.22] WIP TAC Life Support 0.5 [17Nov]". I also include a file in the build that has version information, like "TacLifeSupport_v0.6.13334.4.txt".

In my opinion, instead of getting people to standardize on your scheme, try to get more people to include version and last modification date information into the forum thread's subject and include something in the release that tells you which version you have installed. It frustrates me right now because I cannot go to my GameData directory and open some mod and see what version I have. There is nothing in the directory that tells me, and I cannot right click the DLL and see a version number either .

[regex]

It's not a bad idea but I'm not really keen on remembering this scheme every time I create a release, which is pretty infrequently, so I'll use my own versioning scheme, thanks.

E: I also think this version scheme is very confusing for users; it's long and has cryptic elements. IMO a much better scheme would follow the form 0.22v0.7, and even that looks a bit unwieldy. Maybe 0.22-0.7 (<KSP version>-<mod version>)? That's something that would make sense to users and modders alike, is very easy to remember, and more easily accommodates different numbering schemes without ending up looking like a bunch of gibberish.

In my opinion, instead of getting people to standardize on your scheme, try to get more people to include version and last modification date information into the forum thread's subject and include something in the release that tells you which version you have installed. It frustrates me right now because I cannot go to my GameData directory and open some mod and see what version I have. There is nothing in the directory that tells me, and I cannot right click the DLL and see a version number either .

This is a good idea too, I'm going to start putting the version number in the main window title.

Edited December 3, 2013 by regex

[Kilmeister]

Not a bad idea, but I think you may over complicate it for some people. I'm sure anyone who's ever fired up an IDE like Visual Studio will have no problem with your scheme, but I imagine some of the modders out there who are just doing artwork and models may not be as familiar with the concept. But, I'm sure they could get the hang of it quickly if a brief tutorial was put in the mod submission rules as a suggested(not required) naming context.

[Azivegu]

I am not familiar with the Visual Studios ID form Taranis, but that is something that needs to be taken into account. I think that the build date for you would be more important then for your end users as you update your files more frequently than we do. So maybe there is a workaround that somebody knows of. The versionID (why not just call it VID) is supposed to give vary basic information. The letter isn't even a requirement, the only reason I kept it there is to make it easier to read. Maybe a short version from v.0.22.a.1.33.2 -> 22.1.33.2???

It says pretty much the same thing, but a much more compact version. But anyone any better ideas? I think that it is important to agree on a certain system (like that 1EC=1kW) as to streamline the process for everybody.

@Kilmeister: The way I had it put together is for it to be very intuitive, if of course somebody takes the time to look at it, which knowing some people that might not work out. I would actually recommend that modders only add the the version number to the title of the forum as you want to make it as useful as possible.

I would also recommend to all modders, can you include the VID into the name of your folders? That way nobody has to go snooping around to find something.

Ow, Taranis, not meant to be mean or anything, but your mod was actually the one that pushed me over the edge (as in to do something about it) to standardize VIDs.

[regex]

Maybe a short version from v.0.22.a.1.33.2 -> 22.1.33.2???

It says pretty much the same thing, but a much more compact version.

There needs to be a clear delineation between KSP version and mod version, otherwise it gets confusing. User-facing version numbers should be short, sweet, and to the point.

The way I had it put together is for it to be very intuitive

It's not.

[Greys]

*Standardized

Version numbers are kinda fine already. That is to say, the mods that have posted version numbers, are perfectly fine, there's no advantage to standardizing and in fact I would argue that if we all used the same format it would make it more difficult for players to remember what version of what mod they had when. In this regard, different formats are less easily confused so if there are a small number of mods using each format structure it makes it easier to remember all of them.

As has been mentioned, the only real problem is mods that have no posted version number in the thread title, or no version number at all.

Mixing the KSP version number with the mod version number will also only contribute to confusion, especially when most mods are currently compatible with at least two versions of KSP, but up to five and in rare cases six different versions of KSP. Having the compatible versions listed as a range in the thread title is the ideal and correct way to convey this information, [KSP 0.20.0-0.22.0]

Edit-

Beyond always having the version number and compatibility versions in the thread title, what should be standardized is as Taranis explained, version indicator files that are distributed with the addon so that the player is always aware of what they have installed. I'm a proponent of the MODName.whateveryourformatis.version format

Here's mine

https://github.com/Greys0/HexCans/blob/master/GameData/HexCans/HexCans.0.5.0.version

The advantage of .version as the file extension is that the user can then go to /KSP/GameData/ in a file browser and use their operating system's built in search function to search for ".version", and all of the version tags they have in there will show up in a neat list

Edited December 3, 2013 by Greys

[Hyomoto]

I like the discomfort it causes; the version numbers are usually for the author, and in modding projects are more vanity than function. After all, Universe Replacer is 4.0, FAR is 11.0, MC is what, v37 now? etc... what is a major/minor revision? Don't even get me started on the alpha/beta/pre-release nonsense the internet loves to abuse. I wish we could standardize it, but I think that would require a mandatory class on version theory in addition to any 'policing'.

I definitely like the idea of putting what version it was MADE FOR, and what version it currently IS. After all, at the end of the day, that's the information that the user needs. If I'm browsing, I want mods for the current build. If I'm updating, I need to know if there is a newer version, and for the MOST part, that information is available already. The one thing all authors agree on is 'moar number iz newist', even if they don't agree with how many numbers there should be.

Unless we get a program like the Nexus Mod Manager that automates the majority of this process, I think you are fighting a losing battle here.

[KerbMav]

Actually it would already be helpful if more modders would include the date of an update in the thread headline.

[Specialist290]

Actually it would already be helpful if more modders would include the date of an update in the thread headline.

This. At the very least, it would cut down on the number of times a day I wonder to myself whether or not I've already downloaded the latest version whenever I see one of the mods I'm using climb to the top of the page.

[Majiir]

I was asked to comment on this; apologies for not getting to it earlier.

I will echo what others have said about this versioning scheme being unintuitive and difficult to implement. However, I also want to make another point which pokes at why this is even a topic of discussion:

Version numbers from different mods don't have any relationship. What does it mean if Kethane is at version 0.8.1 and KAS is at version 0.4.4? Absolutely nothing. There is also no question we'd ever want to ask about two version numbers from different mods. Is one more full-featured? Does one have more bugs? The answers to those questions cannot be captured by a version number.

Comparing numbers from the same software is useful. Which version is newer? Is this upgrade a small change or a massive one? These questions can even be more complex. If Product A is compatible with Product B version 1.2.x, we know that we can use 1.2.1 but not 1.3.0.

The other information you've attempted to capture simply doesn't belong in version numbers. It's good information, but it needs to be disseminated through other channels. Version numbers are authoritative; the latest Kethane release was versioned 0.8.1 because I said so. Whether 0.8.1 is compatible with 0.22 or 0.21 or 0.23 is not something I can just will; the answer may be very difficult to determine. It's not particularly useful to publish which version of KSP a mod was built for because that's not a good gauge of compatibility, and you can usually just look at the release date.

In summary: This stuff does not belong in version numbers. There are reasons to standardize version numbers, but those are to facilitate computers answering the questions outlined in the previous paragraph, not answering questions for humans like "what kind of mod is this?" That's what names and descriptions are for.

[Stone Blue]

I'm not a modder, nor even a programmer/coder/modeler....But if everyone will humor me, I'll throw in my layman's two-cents.

I also do not see much need in standardizing version numbers as an end user, the only thing I need version numbers for is to know if there is a newer one than the one I currently have.

As an end user, I would be happy just to see ALL authors at least even USE version numbers at all....Lots of mods I have do not have ANY version listed, so when I download them, i add the best guess at release date to the file name, which works just about as well for me.

I agree, I like seeing the dates in the thread title...But can the thread title be edited to reflect new updates?

Also, I still see a lot of mods that can be a bit confusing as far as meeting the "official" new folder structure...

I would much rather see improvements on THOSE points, rather than a standardized file version format.

Although from the stand point of some authors who have mods/utilities coming that have/will have auto-update for mods, I assume a standardized format would make THEIR lives a lot easier...and in the end make users of those items happy...So in that respect, I guess my vote would be to go ahead and try it.

Edited December 6, 2013 by Stone Blue

[regex]

Although from the stand point of some authors who have mods/utilities coming that have/will have auto-update for mods, I assume a standardized format would make THEIR lives a lot easier...and in the end make users of those items happy...So in that respect, I guess my vote would be to go ahead and try it.

An auto-updater that handled many different mods from many different authors would be able to handle different versioning schemes so long as they followed an increment system, which pretty much any sane developer would probably use. At least, I've never seen anyone decrement their versions...

Edited December 6, 2013 by regex

[Greys]

I agree, I like seeing the dates in the thread title...But can the thread title be edited to reflect new updates?

Yes. It can be updated.

[Stone Blue]

Yes. It can be updated.

Nice to know :thumbsup:...I havent had to try it on this forum, but most I have ever been on do not allow you to edit a thread title.

[Bluegobln]

At least, I've never seen anyone decrement their versions...

Just for grins, I am doing this for anything I make in the future. *cackle*

[John FX]

Myself I would just like the root folder name inside gamedata to be the name of the mod in simple english, instead of i^3 or keramzit or triggertech etc

sorry for using you as examples, you are just the first ones that came into my mind from mods I have installed. I love your mods BTW but without knowing in advance what these mods are, you could not tell from the name what they do.

Compare that to the folders called kerbpaint or tacfuelbalancer or mechjeb2 or enhancednavball or editorextensions or stretchytanks, it is easy to tell what mod they are.

If this change could happen it would make the gamedata folder a really nice place to be

[Vrana]

...stuff about Gamedata folder names...

This i very much agree with.

[Hyomoto]

The other information you've attempted to capture simply doesn't belong in version numbers. It's good information, but it needs to be disseminated through other channels. Version numbers are authoritative; the latest Kethane release was versioned 0.8.1 because I said so. Whether 0.8.1 is compatible with 0.22 or 0.21 or 0.23 is not something I can just will; the answer may be very difficult to determine. It's not particularly useful to publish which version of KSP a mod was built for because that's not a good gauge of compatibility, and you can usually just look at the release date.

I'm surprised at your response, but it fits perfectly into what I said about version numbers being for authors, and mostly vanity. Knowing what version of KSP a mod was designed for IS a good measure of its compatibility. There's nothing to say that 0.21 doesn't work with 0.22, BUT we are aware there may be issues. It's also a useful 'quick glance' to see if it has updated, or if we should even have any interest in it, ie: is it dead? Just knowing that 1.4.3 is more than 1.4.2 is not a useful yardstick in and of itself, more info IS desirable (hence the topic?). But I understand your point, I can prove these are vanity numbers with a litmus test, why use decimals at all? If the number being incremented is all that matters, why bother with a complex scheme in general? Why use 0.8.1? Why not 8.1? Why not just v81? Heck, why not just the date of the last release?

If you are being honest, and you think versioning doesn't relate to the projects around it, then just use the date. That info is more easily recognizable by ANY user, and is always one hundred percent accurate. None of nVidia's 660 GT is weaker than the 560 GTX Ti nonsense. Otherwise you must at least concede that these numbers being useful to the end user is completely secondary to their usage.

[blizzy78]

Just knowing that 1.4.3 is more than 1.4.2 is not a useful yardstick in and of itself, more info IS desirable (hence the topic?).

Read the plugin's change log.

If you are being honest, and you think versioning doesn't relate to the projects around it, then just use the date. That info is more easily recognizable by ANY user, and is always one hundred percent accurate.

The date is just as accurate as any arbitrary version number tacked on by the author. The version number (or date, for that matter) in itself does not convey any meaning. It gets a meaning the instant you compare it to any other version number or date (or the current date.)

[frizzank]

The main reason I would not incorporate the build number of KSP in my own version number is that the two versions are not dependent on each other. Just because the KSP version increases does not mean it breaks your mod, nor do I have to update my mod to work with the latest version in most cases.

Many mods from .18 and beyond still work in .22. Also when you label your mod with a previous version of KSP it gives the impression to the general public that it doesn't work with the most recent version. When in fact it works perfectly well, and will continue to work for some time.

An example of this is my Asteroids mod. It doesn't need an update, so why would I go through the process of changing the revision number and re-uploading it, risking adding a new bug or messing up the download just to update an already arbitrary number? Its not worth the risk or the effort.

[Stone Blue]

Many mods from .18 and beyond still work in .22. Also when you label your mod with a previous version of KSP it gives the impression to the general public that it doesn't work with the most recent version. When in fact it works perfectly well, and will continue to work for some time.

Or worse....might give the impression its no longer supported or abandoned...So why would someone download and try it if it might end up killing their saved games?

[nosscire]

While I don't agree with some weird versioning number, I would like more standardization at the Space Port. For mods posted elsewhere, people can do what they want.

What I want at Spaceport:

Compability: When uploaded, uploader have to set compability. Can naturally be updated later

Versioning: A field where uploader can enter their own version number

Update date: I'm still unsure if uploaders even can update their uploads, or if they have to re-upload? In any case, we need this together with Creation Date.

File history: Where you can see previous updates. I'm fine with text only if they don't have the infrastructure for archiving actual uploads

Changelog: A mandatory changelog for each update (may be filled in with lots of info, or just barebones)

Together with this I would like a standard where a info file must be included in each download, that again includes upload date, version etc. This could easily be added to zip-files by the website itself. It's all great to see that an addon was updated 2 weeks ago, but if I can't remember when I downloaded it last myself?

KSP is in the rare situation where the main source for addons is not some large addon database company (moddb, Curse, Nexusmods etc) but their own website. Unfortunally they have not done anything good with it, but instead created a quite crappy place to dump zip-files.

[Stone Blue]

Speaking of Spaceport, I dont like that they put a "prefix" on all the filenames. ie "uploads_2013_11_".....What good does that do an end user to know it was uploaded to Spaceport sometime in Nov. 2013?.....AND how is someone supposed to organize their mod .zips alphabetically?....So yeah, when downloading every file, I have to delete this "prefix"...