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".

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.