wonko_version_identification.md

How should versions be referenced internally?

Currently we have 2 attributes for version identification: name and timestamp. The name is used for cosmetic purposes; displaying in the UI etc., while the timestamp is used for ordering.

Now, the question is: how should versions be referenced internally? The available options are:

• Using the name
• Using the timestamp
• Using a new attribute; ID

Using name means internal systems need to be able to handle pretty much anything for the version string, including escaping of the name when required etc. Name can also change, even though it really shouldn't (for example if there was an error when first entering the version name).

Using timestamp means the internal systems don't need to guard themselves as much, the value will always be a fixed width integer. The timestamp to can change though, for the same reason as with the name. Additionally it is harder to memorize than the name.

Adding the new attribute, named ID. It would not be used for sorting, thus not need to change. It would also be an integer, thus more efficient to handle with less required guards against weird values. It would still be hard to remember though, and also add yet another attribute.

Which of these do you prefer? Something completely different? Please also state "why".

I prefer using the name - it is a version name and most things have a decent version names. This is what the user sees and knows.

Same for a separate ID. Why exactly do you need more than one ID? There will be a few weird mods that will have to be assigned version names because the author failed to do so... but I don't see that as a problem.

Considering future extensibility:
Let's start with just the ID for identification.
If we ever need a 'name' just for the looks in the future, it can be added. I would rather avoid it though.
The timestamp should be cosmetic / used for sorting where no explicit order is established.

Sorting by timestamp is actually a workaround for derpy version numbers and neither cover the case where you have parallel branches - think stable vs. develop versions of MultiMC. So, that's maybe a separate concern that should be looked at. I'd like to use this wonko system for MultiMC updates at some point...

Why: the alternative is to use a horrible number that is impossible to remember, or introduce extra fields that will just pollute the schema. It is the only good alternative IMHO

Here is a different variant for versioning:
Let versions specify the previous version(s).

Or specify the next version(s)!

What do you mean by "internally"? Internally within the format, or internally to MMC (or other consumers of the format)?

I use numeric ids for now, for multiple reasons, the main one being that they can be assigned by my system and never change afterwards, but everything else can change. But each system would then have its own private mapping of ids to versions, so this id doesn't need to be public in the format – unless you want to use such ids internally in the format itself to refer to versions. Then the problems with it being difficult to remember mentioned by @peterix apply. I would try to avoid that in human formats.

As for @peterix's comment on referencing parents, this is not a bad idea. The order on versions is only a partial order, after all. Not all versions are comparable when projects have branches (such as BC). But it makes for more data entry work. I've thought before about how to simplify this so that nobody has to enter Git-style predecessor lists, coming up with branches/variants. But projects use this so rarely that I've spent no extra time implementing it.