Soulthieves, SouthLab: version number notes.
This is highly boring stuff, unlike most of what I write here. But this is basically a technical note for myself on a metagame detail, the software's version number. The format is already on the front page of the manual, and it's this:
x.y.z.a.m.d.b
This would be the full version. The basic public version would be x.y.z. The reason for so much detail in the number, aside from thoroughness, is to facilitate archiving, bug tracking, version history and software update checks, probably among other things. For example, if I add a bugfix that creates a new bug itself (discovered later), I can track back through versions to pinpoint exactly where I produced the bug. Plus, it looks cool, and inflates importance. Transience of each component, and the subtlety of their referenced changes, generally increases from left to right (meaning x tends to be the least changing while b is the most, from a technical standpoint).
Breakdown:
x.y.z is the public version number. Not that the full version number wouldn't be available publicly to those who seek it, but this will basically be the front page number on the Internet. It indicates generally greater changes than the rest of the full number and is the strong recommendation for a software update.
x - major version reference. This changes only when new features are introduced. It may also change if many sweeping changes are made to features already implemented or if features are removed. This is generally not changed for bugfixes.
y - lesser version reference. These changes are still important. They adjust or rebalance features added to the latest major version or fix glaring (though not necessarily fatal) bugs that cause a feature to behave incorrectly. These changes should not be thought of as mere "tweaks". y is subordinate to x, and is automatically reverted to 0 when x changes.
z - minor version reference. These changes are important enough to not fly under the radar. These would generally be confined to behind-the-scenes bugfixes; these are important in that it's the behind-the-scenes bugs that obviously cause stability issues (i.e. unexpected crashes). Though typically lesser in scale to y changes, these ones are obviously a stronger case for updating the software. This becomes relevant when some people like incorrect feature behaviours that would be corrected by a y change but, should they choose not to update, are then thus at the mercy of the z bugs. y changes can themselves produce z bugs, but sometimes bugs can fester behind the scenes for a long time before anyone actually comes across them; by then several lesser version changes may have passed. z is subordinate to y, and is automatically reverted to 0 when y changes.
a.m.d.b - date reference (year.month.day.build). This is simply the date I compiled this particular version. Changes to the date reference alone suggest minor fixes to non-fatal bugs, like spelling corrections in text or slight adjustments to features (for example, if I added a new item but its generation chance was accidentally set to zero (for important items this would otherwise necessitate a y update)). It may also suggest other subtle tweaks, such as colour changes or slight reformulation of a spell (to, say, make the math more efficient). These changes should not themselves create fatal bugs; if there's a foreseeable chance of that, such changes would be z or y changes. Non-fatal bugs created by date versions can be corrected in a future date version, although in general these changes are minor enough that that shouldn't happen either; further tweaking, however, is a possibility. A date version update is less critical than a public version update and so it won't be publicized as strenuously.
b - build number. This is just a fail-safe and will probably usually be 1, but this is for the event that I compile the program multiple times in the same day; the date reference would thus obviously be insufficient in itself. Basically, each time I compile the program on a given day, I'll increment the build number by 1; it'll be reset to 1 at midnight. Otherwise this doesn't really convey information any different from the date reference and can be considered part of it. Since it's part of the date reference, even if it's always 1 it still technically changes every time the date reference as a whole changes (basically every time the program is compiled).
For example, if I compiled a hypothetical beta version today, the full version number could be 0.0.0.9.10.24.1. The public version would be 0.0.0.
I've gotta figure out a way to get the version number in the manual to change automagically whenever I compile, because it's quite conceivable I'll forget to change it if I have to do it manually.
x.y.z.a.m.d.b
This would be the full version. The basic public version would be x.y.z. The reason for so much detail in the number, aside from thoroughness, is to facilitate archiving, bug tracking, version history and software update checks, probably among other things. For example, if I add a bugfix that creates a new bug itself (discovered later), I can track back through versions to pinpoint exactly where I produced the bug. Plus, it looks cool, and inflates importance. Transience of each component, and the subtlety of their referenced changes, generally increases from left to right (meaning x tends to be the least changing while b is the most, from a technical standpoint).
Breakdown:
x.y.z is the public version number. Not that the full version number wouldn't be available publicly to those who seek it, but this will basically be the front page number on the Internet. It indicates generally greater changes than the rest of the full number and is the strong recommendation for a software update.
x - major version reference. This changes only when new features are introduced. It may also change if many sweeping changes are made to features already implemented or if features are removed. This is generally not changed for bugfixes.
y - lesser version reference. These changes are still important. They adjust or rebalance features added to the latest major version or fix glaring (though not necessarily fatal) bugs that cause a feature to behave incorrectly. These changes should not be thought of as mere "tweaks". y is subordinate to x, and is automatically reverted to 0 when x changes.
z - minor version reference. These changes are important enough to not fly under the radar. These would generally be confined to behind-the-scenes bugfixes; these are important in that it's the behind-the-scenes bugs that obviously cause stability issues (i.e. unexpected crashes). Though typically lesser in scale to y changes, these ones are obviously a stronger case for updating the software. This becomes relevant when some people like incorrect feature behaviours that would be corrected by a y change but, should they choose not to update, are then thus at the mercy of the z bugs. y changes can themselves produce z bugs, but sometimes bugs can fester behind the scenes for a long time before anyone actually comes across them; by then several lesser version changes may have passed. z is subordinate to y, and is automatically reverted to 0 when y changes.
a.m.d.b - date reference (year.month.day.build). This is simply the date I compiled this particular version. Changes to the date reference alone suggest minor fixes to non-fatal bugs, like spelling corrections in text or slight adjustments to features (for example, if I added a new item but its generation chance was accidentally set to zero (for important items this would otherwise necessitate a y update)). It may also suggest other subtle tweaks, such as colour changes or slight reformulation of a spell (to, say, make the math more efficient). These changes should not themselves create fatal bugs; if there's a foreseeable chance of that, such changes would be z or y changes. Non-fatal bugs created by date versions can be corrected in a future date version, although in general these changes are minor enough that that shouldn't happen either; further tweaking, however, is a possibility. A date version update is less critical than a public version update and so it won't be publicized as strenuously.
b - build number. This is just a fail-safe and will probably usually be 1, but this is for the event that I compile the program multiple times in the same day; the date reference would thus obviously be insufficient in itself. Basically, each time I compile the program on a given day, I'll increment the build number by 1; it'll be reset to 1 at midnight. Otherwise this doesn't really convey information any different from the date reference and can be considered part of it. Since it's part of the date reference, even if it's always 1 it still technically changes every time the date reference as a whole changes (basically every time the program is compiled).
For example, if I compiled a hypothetical beta version today, the full version number could be 0.0.0.9.10.24.1. The public version would be 0.0.0.
I've gotta figure out a way to get the version number in the manual to change automagically whenever I compile, because it's quite conceivable I'll forget to change it if I have to do it manually.