- The official title for my current build is "Ancient Domains Of Mystery (release 48)". Displayed on the title screen and in the windows title. Derived from a total of 48 releases (including the next one).
- The internal version number displayed after pressing 'V' is "Ancient Domains Of Mystery (release 48, build 48a, version 1.8.0)".
- Release is just a runnnig number that does nothing but count the number of released versions (hence 48, hopefully I didn't miscount).
- Version is the version number adjusted for the new rules which state that MAJOR (1) will always remain fixed for ADOM, minor (currently 8) will be advanced with each public release that creates incompatibilities (and we could discuss if it then should be 5 or 6 or 7) and MINOR (currently once more 0) is only adjusted for changes that are very minor and do not invalidate save files.
- The numerical part is advanced to the release number, if MINOR or MAJOR changes. The character part is advanced if PATCH changes (and then only the character part).
Jochens first feedback was "Too complicated. I don't like it.".
Which brought me back full circle to the arguments exchanged in the original post:
- I want to reflect the advances state of ADOM (hence release 48).
- Some people prefer MAJOR.MINOR.PATCH schemes (thus the internal version number 1.8.0).
- Some people just want to have a little more information but are happy with not being flooded with meaningless information - hence "build 48a".
Now I just could go with the build number - but wouldn't that be kind of equal to dropping the "1." from the version number and just going with the second and third number? So 8.0? (or 7.0 or 6.0 - the numbers right now are not yet important)
I guess I shouldn't try to decide this in a democratic way ;-)
When I do my own numbering, I tend to go by Major.Minor.Extremely minor/bugfix/patch/whatever my own self. Mind you, I number text things.
ReplyDeleteSo if I wrote an entire new section, or added a big chart that wasn't there before, or did an experiment, or rewrote the way something was written entirely, the version would change (so 1.0.0 would become 2.0.0).
If I just adjusted what was already there, but did it in a big way (added more numbers, added another paragraph, re-did the math and corrected it) then I'd make it a minor correction (so 1.0.0 would become 1.1.0).
If I did a spellcheck, corrected someone's name, updated the copyright, or added or removed some things from the 'thank you' section, I would do a 'ugfix' sort, since nothing of note was changed; just cleaned up (so 1.0.0 would become 1.0.1).
This is just my personal preference, and may not reflect those of others. :)
Since you're trying to get coverage, publicity, more users, you should err on the side of simple and communicating "this is not pre-release, this is done"
ReplyDeleteSince only the hardcore even care, leave the versioning stuff to whatever scheme you want, build # or date, but just have it be ADOM. And if people want to know the version, they can go in-game and hit V.
Think about it, almost all releases are soon surpassed by the next one, so who cares. The only exception with ADOM is 1.1.1 which has special meaning since it lasted without update for so long.
Would "semantic versioning" be useful here? It's a specification that gives semantic meaning to each of the version number segments and gives guidance on when to increment each piece.
ReplyDeleteGiven a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.
It seems to be written for services/APIs, but I bet it could apply to games. The "API" could be the save game format or something. That's your interface with the filesystem and the player (when upgrading their binaries).
This way, too, it's not a democratic process, but an objective one :)
http://semver.org/
I think my biggest problem right now with semantic versioning (if it is a problem at all) is that so far version increases with ADOM have been extremely conservative. The jump from e.g. 1.2.0p22 to 1.2.0p23 IMHO was big enough to warrant at least a 1.3 and maybe a 2.0 (because the changes were incompatible in data structures). But people are not accustomed to it so far ;-) And many major ADOM changes probably immediately would increase in the first number :-) If I'd just to back port that logic to the 1.2.0p23 releases we probably by now would be at version 16.0 or so ;-) That's also the reason why I came up with the "release number" scheme almost equal to the one in Firefox and Chrome. Most releases of ADOM contain pretty interesting changes and most of those break the current game code/API ;-)
DeleteAbout dropping the 1 in front... I've always seen that as a sign of a completed product. Which is of course arbitrary, but well, it sort of states "this is not a beta any more" as opposed to 0.9.9 which meant "still a beta".
ReplyDeleteNow, ADoM 1.8.0 is fine. ADoM 8.0 is "what?! ADoM 8?!"
I like it... a lot actually, its a great compromise - however if you're keeping the version number, will it also track patches by incrementing the minor number? If so, drop 'Build' - it aint needed.
ReplyDeleteYou can easily see what Release you're on, allowing you to easily discuss the game both meaningfully and casually (ie, "nah, I really liked Release 51, the new mobs were unbalanced sure, but so was their loot, Release 52 changed that and the Wolpertinger has never been the same since"). If, however, you want to make sure you've got the latest patch or want to report a bug, you can look at the Version number. It's easy enough to understand with just the two tiers.
Casual players just don't care about patches; they'll either update automatically; only ever update when major new content is added (new Release); or only look into updating if they've specifically run into a bug and want it fixed. In two out of these three events, they wont look at anything other than the Release number. In the last, they'll generally be directed towards the latest build anyway in a "see if that works" mentality.
More technical minded individual who care to look at change logs and file bug reports, and generally follow exact incremental changes have all the information they'd need with the Version number.
So really, who is the Build number for? Either drop it, or roll the lettering method of noting patches to the Release number (effectively dropping to two notations still, but just keeping the name Release but applying it to the Build notation).
'least, that's what I'd do.
I like the proposed scheme. Just make sure you never get to 2.0. Just go to "1.10" after "1.9", etc. Since you probably will need to break save game compatiblity and stuff like that you probably want to have a scheme for that in parallel to simple release numbers. So I think it makes sense to have the major.minor scheme running in parallel.
ReplyDelete1.x.y is what's standard across all games. You'd confuse people by adopting a browser-based numbering system. The numbers are generally kept hidden though. Especially on Steam, where you just get updates in the background.
ReplyDeleteAnd currently I'm pondering certain points where even the "1" might change, e.g. when entering major new platforms. Like "2.0.0 for entering Steam", "3.0.0 for being on iOS", etc. But we'll see ;-)
Delete