Versioning

OK, here's the spec for how version numbers should be managed across ProgClub projects (from now on).

We will endeavour to be compatible with Semantic Versioning (v2.0.0 at time of writing).

So our semantic versioning is: MAJOR.MINOR.PATCH[-BUILD.REVISION]

Our MAJOR.MINOR component will be resident in the Subversion path, e.g. project/branches/3.0 for MAJOR.MINOR version 3.0. The MAJOR and MINOR version numbers will also be in software constants (see below).

Our PATCH version will not be in the Subversion path, but will be in a software constant (see below).

Our BUILD is one of, e.g. 'dev', 'test', 'alpha', 'beta', 'prod', etc. The BUILD is specified in the config file, not in the software. If the BUILD is unspecified the BUILD.REVISION component of the version number is omitted.

Our REVISION is the Subversion revision number of the software. The REVISION is calculated by running 'svn info' and retrieving the 'Revision:' value. The 'svn info' command can be run at install time with the REVISION stored in the config file, or if there is no setting in the config file then 'svn info' can be run at runtime. If the REVISION cannot be determined it is zero.

Build codes

OK, so at the moment supported build codes are:

dev	software is under development
test	software is running unit tests
alpha	pre-release software (never actually used it!)
beta	initial release for testing
rc-1	release candidate one
rc-2	release candidate two (and so on)
prod	software is running in production but interface might not be stable
N/A	when there is no build type the software is released at the indicated version

Software constants

So minimally we'd have:

define( 'VERSION_MAJOR', 3 );
define( 'VERSION_MINOR', 0 );
define( 'VERSION_PATCH', 0 );
define( 'VERSION_BASE', VERSION_MAJOR . '.' . VERSION_MINOR . '.' . VERSION_PATCH );

The above four constants are "hard coded" into the software by the developer. It's the developer's responsibility to ensure that the values are correct and in sync with the project branch name in the repository.

Then we'd need to load our config file, which may have a BUILD type, e.g.:

define( 'VERSION_BUILD', 'dev' );

There might also be a REVISION in the config file, e.g.:

define( 'VERSION_REVISION', 1234 );

After loading the config file the full version must be calculated. E.g.:

if ( defined( 'VERSION_BUILD' ) ) {

  if ( ! defined( 'VERSION_REVISION' ) ) {

    // note: parse_svn_info_revision() returns zero on error
    define( 'VERSION_REVISION', parse_svn_info_revision() );

  }

  define( 'VERSION', VERSION_BASE . '-' . VERSION_BUILD . '.' . VERSION_REVISION );

}
else {

  define( 'VERSION', VERSION_BASE );

}

Happy days!

p.s. If your program is just an application you can use constants such as VERSION_MAJOR, VERSION, etc. If your program is a library you should scope your constants, e.g. PHPBOM_VERSION_MAJOR, PHPBOM_VERSION, etc.

p.p.s. If your programming language doesn't allow for generation of constants at runtime, you will need to model the BUILD and REVISION values some other way. E.g. as global variables, static variables in accessor functions, etc.