Version Number Scheme

This page outlines the logic behind Arx Libertatis version numbers. Like anything else, it's more of a guideline than a hard rule and subject to change at any point.

Terminology

AL version numbers are made up of up to three components:

major.minor.patch

if the patch level is '0' (the first release of a minor version series), it is omitted and the version is written as

major.minor

Development snapshots append the -git suffix and - if build out of a clone of the git repository - a 5-hex-digit prefix of the sha1 hash of the latest commit. The version number used here is the latest one included in the snapshot, which may or may not be the latest released version:

version-git + abcde

Patch Versions

Patch versions are meant for bug fixes and smaller changes that are not part of a significant improvement or new feature.

Patch versions should not introduce new dependencies or change the build process significantly. They are meant as drop-in replacements for both users and packagers so that releases can occur frequently.

Minor Versions

Minor versions can be used to introduce new features or make larger changes to the code. Each significant feature may result in a new minor version, but multiple features can be bundled into one release if it makes sense to do so or if multiple features happen to be ready at the same time.

Each bullet point in the Project Milestones (not just each numbered milestone) could have it's own minor version - although the order doesn't have to match that list. Some bullet points may even be split up into several minor versions.

Besides omitting the third part of the version number, minor (and major) versions also get a nickname to distinguish them from patch versions.

'Minor version' is somewhat of a misnomer as each 'minor' release is still very significant. However in the grand plan they are not the biggest unit of change. Maybe someone can come up with a better term - 'minor version' is just what the number after the first dot is usually called.

Major Versions

Major versions ... well, to be honest I'm not sure where we should draw the line and increment the major version number. Maybe major versions will roughly correspond to each numbered milestones in the Mission statement.

Feature-wise, major versions will probably not bring a greater number of changes than the minor versions, but rather represent a point where we can say that AL has become so much better since the last major version that it's time to spam the world again.

Major versions could also be used to indicate a break in compatibility for user data such as save files - but we should avoid that if possible, or at least provide (automatic) conversion tools.

Development Process

In the foreseeable future we will probably not create patch releases for older major or minor versions, but instead focus on improving the current released version.

Smaller patches are usually applied directly to the master branch. When enough changes have accumulated or we feel like it, the result will be released as the next patch version (possibly after a short testing phase).

Larger changes can happen in parallel feature branches. These feature branches will be merged to master whenever they are ready and then become the next minor or major version.