[RedMatrix]

I was just wondering why some software's version numbers have 2 digits, others 3, and still others 4 (or more! IE, etc)

What is the significance?

For example: VB v3.6.0

It was short lived, but work with me here, folks. I get the first number. It means it's a MAJOR code change. Version 1 > Version 2. But if it's a minor change, they add a 2nd column number. But why more numbers?

Is there a minor-minor version? If so, then a 4th column / digit means a minor-minor-minor version change? WTF?

If *I* were to instigate version number protocols, I would dictate that the first
number be designated Major Code revision (51%+), and the second number be
Minor Code revision (49%-). The third and fourth numbers should be allocated
for security updates and function/aesthetic changes, respectively. This way the numbers
would make some kind of sense; intuitive if you will.

Referring back to vBulletin's latest changes, version # 3.6.(2,3,4,5) were all security updates, while 3.6.6 was function/aesthetic, and now 3.6.7 is another security patch.

I surmise that if my intuit SVP were to have been used, the version numbers since 3.6 gold would have been:
3.6.0.0 [GOLD. (trailing zeros not needed)]
3.6.1.0 [SECURITY UPDATES]
3.6.2.0 [SECURITY UPDATES]
3.6.3.0 [SECURITY UPDATES]
3.6.4.0 [SECURITY UPDATES]
3.6.5.0 [SECURITY UPDATES]
3.6.5.1 [NEW FUNCTIONS (blog, etc)]
3.6.6.1 [SECURITY UPDATES]


Anyhoo... that's my beef today. Maybe I should blog it.

[Moelman]

I think like in your example with vB, they follow a similar pattern that you detail except they use the same digit for security fixes and new functions.

In the second digit I think it depends on the number of new features added for how many digits they go up. Like with 3.0 --> 3.5, it was a huge overhaul but with 3.5 --> 3.6 there were new features added but not near as big an upgrade as the 3.5 upgrade.

[Tikitiki]

I believe, that the x and y in x.y.z should be just a integer that acts like a tens digit column. For instance: Say you have vB 2.9.0 (which was a MAJOR release) and then they come out with another MAJOR release, it would be labeled 3.0.0 (29 -> 30)

At least, that's how I think it should work.

And the y should just be minor feature additions and security releases. It makes more sense to proportion it that way. Bigger numbers should mean bigger releases.

[LarryB]

In typical Software development you have Major.Minor.BuildNumber . With a PHP application there isn't a build process, so a lot of PHP developer do Major.Minor.Patch

[Jolteon]

I personally do
A.B.C.D
A: Version number.
B: Incremented when a new patch, or bug fix is released
C: Incremented every time there is a code change
D: Development Stage Letter. (A: Alpha, B: Beta, RC: Release Candidate, G: Gold)

[bdude]

I've always liked the phpBB way of x.y.z
x = indicates major change, no backwards compatibility
y = indicates the minor version, new features with backwards compatibility to all x versions
z = a minor patch e.g. security flaw

[Oldiesmann]

For SMF:

Betas:
BetaX - Typical format here (X = beta number)
BetaX.Y - Indicates a patch/minor revision for the beta
BetaX Public or BetaX.Y Public - Indicates that this is a public beta that was released to Charter members first. Generally this is used when there are changes between the initial beta release and the time it gets to the public.

Release candidates:
RCX - X indicates the release candidate number.

When a patch or minor update is released in between RCs, the version number in the footer doesn't change, but the version number of any patched files gets changed to "RCX-Y" (RC2-2, etc.).

Stable release:
X.Y - X is the major revision, Y is the release within that revision/branch. Y is incremented whenever a new version is released, but indicates that while there were significant changes, it is not a complete overhaul/rewrite.
X.Y.Z - Used for patches/minor updates (1.1.2, 1.1.3)

[RedMatrix]

I'm glad there's a protocol for that, then.