Iterative Versioning - 2019.01.02 - English
Iterative Versioning

Iterative Versioning - 2019.01.02 - English

Publicationdate: 2019-01-27T10:53:43+01:00

Version numbers

TL;DR year.sprint-or-production-release.build(-ADDITION)

Iterative versioning knows the following format: x.y.z(-ADDITION), where the letters represent the following values.

Letter

Meaning

Explanation

x

Year

Where the x is sometimes used to indicate a miajor release, it makes more sense to use the year in which the build was made. Togheter with the sprint or production release, you should be able to identify when the release took place.

y

Sprint / Production release

It's useful to increment this number after every sprint, because you can deduce retroactively which was the last version that was release to production.

z

Build

For the sake of iteration, it's very useful to increment this number, each time you build a release that will be deployed to one of the environments on your (d)TAP.

(-ADDITION)

Clarification

The terminology snapshot was once brought to life to indicate that the current build was a snapshot of the code at any given time and therefor was not a production ready build artifact. This is used in projects where the code can be checked out by third parties. The addition snapshot indicates that changes are likely to be made in this release in the future. With software that is beeing used by only one projectteam, the usage of this addition isn't always neccesary. You could use this addition however to clarify the use or purpose of this release. For example if you're building a release to test specific functionality.

Versions and releases - flow

TL;DR Git flow

Here you find a flow of how the versioning relates to the release process.

iterative-versioning-2019-01-02-s180x180.png

When to use Iterative Versioning?

TL;DR no end-users.

Is your team the only party that works with the software? Do you use agile methodologies? Use iterative versioning.

Why not semantic versioning?

Where the semantic versioning scheme aims at informing the third party user of how this version compares to it's predecessors in terms of compatibility, iterative versioning aims towards informing the developers of the software itself.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MAY contain leading zeroes. X is the year, Y the sprint of production release and Z the iteration. Every element MUST increment numerically, for instance: 2019.01.01 -> 2019.01.02 -> 2019.01.03.

  2. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

  3. Version X.01.Z defines the first production release, where X is the year of the release and Z the number of iterations that took place.

  4. Sprint or producion release Y (x.Y.z) MUST increment MUST be incremented when either a new sprint is started, according to Agile methodogy Scrum, or when a production release has taken place. After sprint or production release Y has been incremented, iteration Z (x.y.Z) starts with 01.

  5. Year X (X.y.z) MUST be incremeted when a new calendar year starts. Sprint or production release Y AND iteration Z both start with 01, when year X increments.

  6. A pre-release version MAY be clarified by adding a hyphen, followed by a series of ASCII alphanumeric capitals, numbers and hyphens [0-9A-Z-]. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. For example 2019.01.01-TEST, 2019.01.01-ALPHA, 2019.01.01-TICKET-NUMMER-01.

  7. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the iteration (Z) or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].  Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 2019.01.01-ALPHA+001, 2019.01.01+201901011130, 2019.01.01-BETA+exp.sha.1567f99.

  8. Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into year, sprint or production release, iteration and pre-release identifiers in that order (Build metadata does not figure into precedence). Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Year, sprint or production release, and iteration versions are always compared numerically. Example: 2019.01.01 < 2020.01.01 < 2020.02.01 < 2020.02.02. When year, sprint or production release, and iteration are equal, a pre-release version has lower precedence than a normal version. Example: 2019.01.01-ALPHA < 2019.01.01. Precedence for two pre-release versions with the same year, sprint or production release, and iteration version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 2019.01.01-ALPHA < 2019.01.01-ALPHA-1 < 2019.01.01-ALPHA-BETA < 2019.01.01-BETA < 2019.01.01-BETA-2 < 2019.01.01-BETA-11 < 2019.01.01-RC-1 < 2019.01.01.