Jump to content

Release Numbering System


icelus

Recommended Posts

I understand the arguments have have been made for decimal releases, and while I don't necessarily agree with them, I see why people use them.

 

What I really don't understand, however, is what's the reason for adding alpha characters to the end of a decimal release?

 

For instance, why call something 6.42a, and not 6.43, or why not even 6.5??

Link to comment

I concur my numbering system is generally horrible.

 

With BGT I started with numbers less than 1 (0.8, 0.9, 0.99, etc.) in decimals until I 'thought' I implemented everything I wanted to (1.00), but after 0.99 I wasn't quite finished, so it ended up 0.99 ZETA (maybe equivalent to 0.999). While 1.00 sort of marked the first 'stable' release, of course, nothing ever finishes, and the numbers keep ramping up. Since I was already working in 0.01 increments, jumping straight to 2.00 would sound remarkably over-exaggerated. And then I started introducing a's and f's within the same decimal number to mark small changes not worthy of getting a whopping 0.01 increment (sure, I could have used 0.001 increments too).

 

But really, who cares as long as people know what the latest version is and you don't attempt to trick them by going downwards in number or backwards in alphabet? I imagine people will be uber-confused if you release version 8 of a mod and the next version was going to be version 7.

 

For instance, why call something 6.42a, and not 6.43, or why not even 6.5??
People, even myself, get a false sense of interval. We trick ourselves into thinking that the changes we made to get from 6.42 to 6.42a is too small to warrant a change from 6.42 to 6.43, and you'll understand why 6.5 becomes out of the question. I repeat: a false sense of interval.
Link to comment

I've always thought there was a concept of "major" and "minor" versioning in software releases.

 

Major = whole number increase, and you've done some significant development (subjective perhaps, but let's leave it there for now). And no, that doesn't mean "let's stuff a whole bunch of changes into the next 'bugfix' just to get a whole number release... :)"

 

Minor = one decimal place (e.g. 3.1) for bugfixes mainly.

 

Anything beyond that is pretty silly. But then so is "here's version 3.1". Oh yeah, download the "August" date-stamped version, where we corrected an overlooked typo in the title, not the "May" 3.1.

 

Call it 3.2 or even 3.11 if you have to, if it makes it easier on the end-user (and that's really what it comes down to). You can thank Microshaft for mucking it up further by thinking it was a good idea to version your software by year (i.e. Windows 95) and then by stupid stuff that has no meaning (XP, Vista, ad nauseum).

Link to comment

Since I got my first computer during the Dark Ages of DOS 6.22 and Windows 3.11 it was only natural for me to use the common numeric software versioning scheme with three numbers separated by a decimal point. The first number indicates a major revision, the second a minor revision and the third a maintenance revision.

 

Anyway, for me, a major revision means that the software (i.e. the mod) has had a significant (often conceptual) change in content from the last version, whether by an inclusion of a large number of additional features or through a major overhaul of the key features. OTOH, a minor revision means that some new features were added or that some small changes to the existing features have been made. A larger gap between two minor revisions indicates a larger quantity of the changes, but still nothing so conceptually different that it would warrant a major revision. Finally, a maintenance revision means just fixing bugs, resolving compatibility issues or adding new translations. Personally, I find this to be the clearest way to indicate the magnitude of the changes between different software releases, but to each their own I guess.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...