DESC: Distinct Editions of Stunts Catalogue

[Daniel3D]

Mod edit by Duplode: The discussion about which version numbers to use for the Stunts NoRH Edition led Daniel3D and me to come up with a system for catalogue numbers that can potentially be used by other custom versions. An outline of the system and the catalogue itself is now available at the (still incipient) DESC number Wiki article, with "DESC" being short for "Distinct Editions of Stunts Catalogue".

V1.3 communicates not compatible with other versions more than anything else.

V1.3 communicates increment over the existing versions.

If I were to release a version that disables the "Restart driving" menu item, what would that be? It can't be V1.3 as well, even if it builds on V1.2, but it also cannot be V1.4, because it does not include the changes in V1.3. By choosing V1.3 you take "ownership" of the sequence, for something that in my opinion branches out of the main "Stunts", into an exciting experiment.

Let me chew on it for a bit..

Ok. It was Duplode that came up with a global version concept to address them.

It could be added to the official releases to help identify them. So i will mention what they could be (in communication and documentation, not to change the game version itself)

It's basically a [project number][year counter][version counter]
The initial release being year 0.
It would look something like.

BB and MS are project 1
Amiga is project 2
PC-98 and FM towns is project 3
My initial rebuild is project 4
Ferrari edition is project 5
NoRH version is project 6

So an added global version
BB 1.0 would get 1.0.0
MS 1.1 would get 1.0.1
BB 1.1 would get 1.1.0
MS 1.1 would get 1.1.1
Amiga would get 2.2.0
98 would get 3.3.0
FM would get 3.3.1
Rebuild becomes 4.31.0 and 4.31.1
Ferrari becomes 5.31.0 and 5.31.1
NoRH 6.33.0

[GTAManRCR]

I don't advise anyone to overhaul the original releases version numbers. Keep the new format for the forked versions only

[Daniel3D]

I don't intend to change anything about the original version numbers.
But they are not very clear.
This new system is just an idea that can also be applied to the originals if you want to compare or research the versions.
Opposed to comparing version 1.1 against 1.1 and 1.1.... 

[GTAManRCR]

Or 4-D Sports: Driving against 4D Sports Driving (Please remember the title screens of the two Mindscape releases for DOS) I'm not sure why Mindscape versioned 4-D Sports: Driving as 1.1 when it is the initial release, and also 4D Sports Driving, which is the second

[Duplode]

As Daniel notes, for the original versions the new numbers won't replace the original ones -- in fact, for them they aren't even meant to be used in everyday talk. We have defined them because the easiest way to have a system of unique version numbers for custom versions that can't be confused with those of the original versions is extending it to include the originals too.

[dreadnaut]

Think about DOSBox. Would you prefer to have DOSBox, DOSBox-Staging, DOSBox-ECE, ... or DOSBox 1, DOSBox 2, DOSBox 3?

Which one are you going to remember? Which one tells you something about what it does?

My suggestion would be

- Stunts / 4D Driving: leave them be as they are
- Stunts - Ferrari Edition  (versioned as the project prefers)
- Stunts - NoRH  (versioned as the project prefers)

Opposed to comparing version 1.1 against 1.1 and 1.1.... 

I'm not sure why you want to compare them. There are fixed number of original versions, which we usually call "by name" (BB1.0, BB1.1, Mindscape, Amiga, FM Towns), and there will be an increasing number of projects based on one or more of the original versions. Each will be driven by different people, for different reasons. Trying to fit them all preemptively into a versioning system sounds doesn't seem useful, and it's anyway impossible to enforce.

For most projects you would only care about the most recent version anyway 🤔

[Duplode]

- Stunts / 4D Driving: leave them be as they are

No one wants to replace the original version numbers. Think of the proposed system as an independent indexing for a catalogue, which can be used in very specific situations in which it is useful to have unique identifiers. It is fine if you don't want to use it to refer to the original versions, that was never the intention anyway. Nonetheless, modders can, if they want, use it as a basis for numbering their own projects, as Daniel currently plans to do.

[Daniel3D]

It could be added to the official releases to help identify them. So I will mention what they could be (in communication and documentation, not to change the game version itself)

We have defined them because the easiest way to have a system of unique version numbers for custom versions that can't be confused with those of the original versions is extending it to include the originals too.

So the numbering is for the Compiled new versions. But can be retrofitted to the original versions. They are not included, but also not definitely excluded. They have been taken into account.

To make it more visual. I added a section to the versions page in the wiki.

[dreadnaut]

To make it more visual. I added a section to the versions page in the wiki.

This is probably a situation where I'm thinking in context X and you are thinking in context Y, and we are both surprised by what the other is writing. Bear with me as I dig further 🙏

I can't understand why you want to define what looks to me like an artificial and obscure versioning scheme, where perfectly readable alternatives would convey the same information, and more.

In particular:
- Why a project number, instead of a project name or abbreviation?
- Why an undecipherable "years since 1990", instead of... the year it was released?
- Why 6.31.1 instead of norh 2023.1?

What problem do you solve by using numbers that require an external source of truth to be understood?

[edit] I think I want to maximise clarity, universality, and minimise the number of moving parts. I feel your proposal values above all... I'm actually not sure! numeric purity? disc space? version-schemes-should-have-three-number-ness?

[Duplode]

(I have spun the versioning discussion into its own thread to avoid derailing the NoRH version one, and also because the topic is of independent interest.)

I can't understand why you want to define what looks to me like an artificial and obscure versioning scheme, where perfectly readable alternatives would convey the same information, and more.

It went roughly like this: to begin with, Daniel had chosen a version number for the NoRH version. You saw a claim of ownership implied in his choice, and objected. We talked about it, trying to find a compromise that would keep something of Daniel's original vision while being impossible to be confused with the original game versions. I came up with the idea of tackling it with a global catalogue number, an approach I also find somewhat interesting for independent reasons, and we hashed out the details together.

Why a project number, instead of a project name or abbreviation?

Aesthetics: numbers-only makes for a prettier version string, and abbreviations can't be sorted in any meaningful way.

Why an undecipherable "years since 1990", instead of... the year it was released?

Aesthetics: using the actual year number would make it look too much like a date, or a year-month pair, in certain contexts. Also, since our year zero is 1990, it isn't so hard to decipher for custom versions in our era -- take the two-digit year number and add 10.

(It should be noted that the point of the second number is not cosmetic, but rather making the catalogue numbers for custom releases obviously distinct from the version numbers of the original versions. An interpretation that makes them not be completely arbitrary is a bonus, and not a requirement.)

Why 6.31.1 instead of norh 2023.1?

The first number can be omitted if the project is obvious from context and there is no other reason to mention it. For instance, it would be reasonable to have the Options menu version string as "Stunts NoRH 33.0".

What problem do you solve by using numbers that require an external source of truth to be understood?

There are two sides to this question. On why to have a global catalogue number, I can think of a few potential use cases:

• If nothing else, maintaining the catalogue can be a shortcut towards documenting and keeping track of newly released versions.
• A modder who approves of our aesthetic choices might opt to borrow the numbers for their version numbers, as Daniel plans to do.
• Some new software tool that has to deal with game versions might use the numbers as unique identifiers, internally or else, rather than having to make up something out of whole cloth.
• At some point, we might have enough custom versions around that using the numbers as shorthand could prove convenient for things like bug reports.

Granted, most of those are hypothetical right now, but they feel enough to make it worth trying out.

As for the single point of truth objection, while the catalogue maintainer is indeed a "single point", I'd question the extent to which "truth" applies here. The catalogue is an extrinsic tool, to be used for specific purposes to which it is deemed appropriate. We are not trying to pass it as an intrinsic source of truth. The actual source of truth here is beyond our control: at the end of the day, 1990 Mindscape and 1991 Mindscape will still have conflicting version numbers etched in their code. If you allow me a metaphor, it is less a matter of computer science than of natural history, less of domain models than of sky catalogues. 


I find the catalogue idea interesting enough to keep it as a separate little project, so I gave it a name and started a stub article on the Wiki for it. No one is forced to use it -- and if you want to start your own rival catalogue, be my guest! -- but it's there if you like it.

[Daniel3D]

I like the system because it translates into original versions very similar to the version number they have. But at the same time make new releases very Distinctive Software indeed.   

[dreadnaut]

Aesthetics: ...

Can't fight aesthetics :gives-up:

As for the single point of truth objection...

Bad choice of words on my side, I suppose. Shouldn't post that late in the night.

What I wanted to argue for was semantics. The catalog number looks like a version number, but it is not — or only partially. About (population of earth - 15) people will look at those and be confused. That's because it makes up new conventions, and hides the explanation, the meaning, is in an external source. Probably a wiki page that will clarify what those number are about, why there's a bunch of 30s, and how this is not actually a version number.

It works well in a little circle, for the handful of people for which it was designed, but does nothing to be accessible and clear to others.

[Duplode]

@dreadnaut The numbers aren't intended to convey meaning; you can pretend they are arbitrary if you want. The point is having unique catalogue numbers that can optionally be adopted as version numbers by project maintainers, and not conveying meta information in a reader-friendly way.  I doubt users in general will be confused to any significant extent, as version numbers being governed by arbitrary (or even ad hoc) rules is the norm rather than the exception. There is no real reason to care about how the numbers are generated unless you feel like adopting them for your projects.

[Daniel3D]

It works well in a little circle, for the handful of people for which it was designed, but does nothing to be accessible and clear to others.

It I think better than all the alternatives we have come up with.
Or did you propose something better? 

[dreadnaut]

Or did you propose something better? 

(Probably not on purpose, but that comes across quite as smug )

That would depend on the definition of better. But I suppose this numbering satisfies all the requirements you care about, so I don't think I can bring anything "better" from  your point of view.