phpBB

Development Wiki

Version Numbering

From phpBB Development Wiki

Versioning Schemes

phpBB employs a versioning scheme which is very common in the software industry. It is a scheme in which different major releases of the software each receive a unique numerical identifier. This is typically expressed as three numbers, separated by periods, such as version 2.4.13. One very commonly followed structure for these numbers is:

major.minor[.revision[.build]]

or

major.minor[.maintenance[.build]]

In most commercial software, the first released version of a software product has version 1.0. Numbers below 1 mean alpha or beta versions, i.e., versions for testing purposes or internal use, or versions that aren't stable enough for general or practical deployment.

In principle, in subsequent releases, the major number is increased when there are significant jumps in functionality, the minor number is incremented when only minor features or significant fixes have been added, and the revision number is incremented when minor bugs are fixed. A typical product might use the numbers 0.9 (for beta software), 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.1.2, 2.2, etc. Developers may at times jump (for example) from version 5.0 to 5.5 to indicate that significant features have been added, but not enough to warrant incrementing the major version number.

A different approach is to use the major and minor numbers, along with an alphanumeric string denoting the release type, i.e. 'alpha', 'beta' or 'release candidate'. A release train using this approach might look like 0.5, 0.6, 0.7, 0.8, 0.9 == 1.0b1, 1.0b2 (with some fixes), 1.0b3 (with more fixes) == 1.0rc1 (which, if it's stable enough) == 1.0. If 1.0rc1 turns out to have bugs which must be fixed, it turns into 1.0rc2, and so on. The important characteristic of this approach is that the first version of a given level (beta, RC, production) must be identical to the last version of the release below it: you cannot make any changes at all from the last beta to the first RC, or from the last RC to production. If you do, you must roll out another release at that lower level.

This is to permit users (or potential adopters) to evaluate how much real-world testing a given build of code has actually undergone. If changes are made between, say, 1.3rc4 and the production release of 1.3, then that release, which asserts that it has had a production-grade level of testing in the real world, in fact contains changes which have not necessarily been tested in the real world at all. This approach commonly permits the third level of numbering ("change"), but does not apply this level of rigor to changes in that number: 1.3.1, 1.3.2, 1.3.3, 1.3.4... 1.4b1, etc.

phpBB's Versioning Scheme in the past

For a long time, phpBB has used a different versioning scheme, related to the Linux Kernel versioning scheme. That is, stable branches have a middle number which is even, and unstable or development branches have an odd middle number. Major versions less than one are also considered unstable. The third number is incremented for maintenance releases. The first number only changes when major code rewrites occur. This is why, for a long time, the next major version after phpBB 2.0 was expected to be phpBB 2.2. During the development of this version, it was decided that the changes were so large that a major version number increase was in order, meaning this version actually became phpBB 3.0.

Because large sets of features were predetermined for stable middle number increments, if this were strictly adhered to, new features would not be introduced very often. For this reason, new features have in the past also been introduced in what otherwise would be considered maintenance releases. In july 2009, the phpBB Development Team announced they would adopt a new version scheme, as described above. During this time, version 3.0.6 was being developed, which was previouisly announced to be a feature release introducing several important new features. It was decided to not change the version number for that release. Should the announcement have been made before development of version 3.0.6 started, that version would probably have become version 3.1.0.