It is necessary to have a unified way to version the artifacts produced by different OPNFV projects and store them on OPNFV Artifact Repository and Docker Hub.

The artifacts that are produced are including but not limited to

• ISO: Produced by Installer Projects to be used for installing OPNFV.
• Docker Images: Produced by Test Projects to ease the testing.

Only the released OPNFV artifacts were versioned for the Arno release. In order to track and record produced and used versions of artifacts, it is needed to apply versions to artifacts produced during development as well.

OPNFV uses versioning scheme similar to Semantic Versioning to version released artifacts as shown below.

  <release_name>.<release_year>.<minor>.<patch>

In OPNFV context, <release_name>.<release_year> corresponds to major version in Semantic Versioning, essentially becoming

  <major>.<minor>.<patch> = <release_name.release_year>.<minor>.<patch>

For example for Arno release, the artifacts are versioned like below

  R1: arno.2015.1.0
  SR1: arno.2015.2.0

The proposal to step version numbers as below:

1. Patch version: Stepped for each and every build
2. Minor version: Stepped when the current OPNFV release is done and on stable/X branch
3. Major version: Stepped when the current OPNFV release is branched off and development work for upcoming release is started on master branch

Based on above proposal, an example scenario for Brahmaputra and C-River releases can be seen on below diagram.

• Brahmaputra development: patch version is stepped for each and every artifact produced
  • brahmaputra.2016.0.1 ← first artifact that is built from the master branch
  • brahmaputra.2016.0.2
  • brahmaputra.2016.0.3
  • …
  • brahmaputra.2016.0.X ← release candidate is built from the stable/brahmaputra branch
• Brahmaputra release: patch version is reset to 0 and minor version is stepped.
  • brahmaputra.2016.1.0 ← released version from the stable/brahmaputra branch
• Brahpamutra bugfixes: patch version is stepped for each and every artifact produced
  • brahmaputra.2016.1.1 ← first artifact on the stable/brahmaputra branch
  • brahmaputra.2016.1.2
  • brahmaputra.2016.1.3
  • …
  • brahmaputra.2016.1.Y ← release candidate
• Brahmaputra stable release: patch version is reset to 0 and minor version is stepped.
  • brahmaputra.2016.2.0 ← released version
• C-River development: major, minor and patch versions are reset accordingly once the stable/brahmaputra is branched off
  • criver.2016.0.1 ← first artifact on the master branch for the criver release

Please note that functionality/NBC changes have not been taken into account for the above scenario.

Releng will provide a script which will calculate the next version to use by checking the latest version that exists on OPNFV Artifact Repository and/or Docker Hub and stepping it by one.

In order to increase the traceability and make cross referencing between artifacts and source code, it is possible to apply tags to git repo on SHA1 that is used for building certain version of the artifact.