SRB2: 1.1 or 1.10?
- Thread starter srb21103
- Start date
- Status
No, it wouldn't. You're trying to say that 1.1 already existed ages ago, and it's now 1.9. The right way to say it is 1.09.9. Here's a small decimal list to help people understand better.
1.09.4
1.09.5
1.09.6
1.09.7
1.09.8
1.09.9
1.10.0
1.11
...
1.19
1.20
1.30
...
1.80
1.90
1.99.9
2.0
1.09.4
1.09.5
1.09.6
1.09.7
1.09.8
1.09.9
1.10.0
1.11
...
1.19
1.20
1.30
...
1.80
1.90
1.99.9
2.0
Blitzzo
It's Mr. Computer!
Well, traditional version systems rely on four different numbers, like so:
Major.Minor.Release.Build
- Major refers to a release that introduces sweeping changes to the program, or perhaps, an entirely new program.
- Minor refers to a release that introduces some new features but is generally the same product.
- Release refers to a maintenance release that simply fixes bugs or security vulnerabilities, and nothing more.
- Build refers to a version that has just been created for some sort of purpose (such as a "daily build" that is used for feedback or bug squashing) and may not have gone through the usual testing.
Thus, the number is not a decimal number. If, for example, a program's version number is at 1.9.9 and a new release is made, that does not automatically mean that the release number turns from 9 to 0 and carries over, resulting in 2.0.0. Conventionally, the next release would be version number 1.9.10. The minor number will only change when there is actually a new minor version out, not when a basic maintenance release is published. Users of SRB2 1.09.3 got to see this rule in action when the build numbers constantly increased as new builds were released on IRC, with numbers like 1.09.3.27.
The only real exception to this that I've seen is when developers have begun work on the next major release (the word "major" is not to be taken lightly), so for a version 5.0, developers may name a WIP version as 4.9.0, and for each maintenance release, count up, eventually to 4.9.9 and then make the official major release of 5.0. However, this only happens on two premises: that they are actually working up to the major release, with the release number as an indicator of how close that major release is, and that they are actually transitioning from an older version/API to a newer one, thus the program is not quite version 4 but not quite 5 either.
The reason that the "final version" will be 1.1 is simple, and has already been stated before. SRB2's version system sucks. Typically, a release of this magnitude would be 1.0, but 1.0 has already been taken up by the Final Demos. And the only reason that 1.09 can transition to 1.1 is because of the leading zero, thus 09 becomes 10 but is treated like a decimal, which is unlike the typical build system.
And yes, the YY.MM version system is also valid, though it suits a different kind of release schedule. Ma.Mi.Re.Bu focuses on the software evolving and reaching key milestones, while YY.MM can be related to time-based releases, meaning that there aren't necessarily milestones, just whatever the devs can get into the next version by the time the next release date rolls around.
Major.Minor.Release.Build
- Major refers to a release that introduces sweeping changes to the program, or perhaps, an entirely new program.
- Minor refers to a release that introduces some new features but is generally the same product.
- Release refers to a maintenance release that simply fixes bugs or security vulnerabilities, and nothing more.
- Build refers to a version that has just been created for some sort of purpose (such as a "daily build" that is used for feedback or bug squashing) and may not have gone through the usual testing.
Thus, the number is not a decimal number. If, for example, a program's version number is at 1.9.9 and a new release is made, that does not automatically mean that the release number turns from 9 to 0 and carries over, resulting in 2.0.0. Conventionally, the next release would be version number 1.9.10. The minor number will only change when there is actually a new minor version out, not when a basic maintenance release is published. Users of SRB2 1.09.3 got to see this rule in action when the build numbers constantly increased as new builds were released on IRC, with numbers like 1.09.3.27.
The only real exception to this that I've seen is when developers have begun work on the next major release (the word "major" is not to be taken lightly), so for a version 5.0, developers may name a WIP version as 4.9.0, and for each maintenance release, count up, eventually to 4.9.9 and then make the official major release of 5.0. However, this only happens on two premises: that they are actually working up to the major release, with the release number as an indicator of how close that major release is, and that they are actually transitioning from an older version/API to a newer one, thus the program is not quite version 4 but not quite 5 either.
The reason that the "final version" will be 1.1 is simple, and has already been stated before. SRB2's version system sucks. Typically, a release of this magnitude would be 1.0, but 1.0 has already been taken up by the Final Demos. And the only reason that 1.09 can transition to 1.1 is because of the leading zero, thus 09 becomes 10 but is treated like a decimal, which is unlike the typical build system.
And yes, the YY.MM version system is also valid, though it suits a different kind of release schedule. Ma.Mi.Re.Bu focuses on the software evolving and reaching key milestones, while YY.MM can be related to time-based releases, meaning that there aren't necessarily milestones, just whatever the devs can get into the next version by the time the next release date rolls around.
supershadow2
Member
"Significant Figures"
- Status