Details on the history and discussions that led to this process can be found at Release Versioning Strategy.

Roll-out Schedule

Java (Maven) Artifacts Release Process

Docker Images Release Process

Prepare your docker images.  Here is the high level flow relating the various Java artifact versions to Docker tags:

  1. Produce SNAPSHOT Java artifact.  Test this in a SNAPSHOT docker image.
  2. Produce staging (release candidate) Java artifact.  Test this in a SNAPSHOT docker image.
  3. Produce release Java artifact by picking one of the candidates from staging. 
  4. Produce STAGING docker image using the release Java artifact.  Use this in E2E test flows.
  5. Produce RELEASE docker image by picking one of the candidate STAGING docker images.

Docker image release process:

Standardized Docker Tagging

TODO: Michael to send out onap-discuss meet for 2nd next PTL meet - based on brainstorming the docker versioning in terms of the CD process (Marco, Gildas, Gary, Michael)

Adding the page ONAP Docker Tagging.

DI 1: Standard Tag Format

Current status within Docker

ONAP Nexus 3 which contains ONAP Docker images is structured as below:

What do we Need stanardardized Docker format

As Docker Snapshot is a cumulative repository, given a version, a keyword and the name of an image, the need is a systematic method to sort chronologically images based on Nexus version field.

This will help to community in providing an automated deployment using tag sets on a standard format.


The proposed docker tag format to align across all the teams is the following:


X.Y.Z follows the Semantic Versionning



See similar examples of the current tag structure by browsing the links below. Unfortunaltly there is no consistency among projects. Note these examples have additional keyword (such as SNAPSHOT) that are currently not deemed necessary. 


Just picking any 2 random here - issue is not any particular project



Raw notes from 20180202 - scheduling a PTL meet for after the vF2F

20180202 Notes:
- Alexis, Marco proposal;
1) which docker tag set to test - latest or timestamp based?
Action: could force either on teams
2) how do we report -1 failure of CD - check docker merge build tag version
(leave how to fix - original tagset or latest tagset to the teams)

tag once on image production -

- central/integration uses released docker manifest - known tested as good
- team declares a released manifest version as good (for now manually by team - later after the CD has marked the version as tested)
- component teams deploy using their snapshot + same released docker manifest for other teams' docker

Proposal: follow nexus.onap.org naming
- latest uses snapshot - follow maven format


proposal: use symantic version v1.1.1 - is released (no latest tag) - unchanged
1.1.2-snapshot is the next under test
1.1.2-timestamp (here we need LF to pick up the format)
proposal: Timestamp-yyyy-mm-dd-Thh-mm-ssZ
or version-yyyymmddThhmmssZ (no :)
fill out and merge Gildas slides
send mail to discuss and meeting 2nd monday

1.1.2-snapshot - points to the "latest" of 1.1.2-timestamp - (are the versions under continuous testing - CD is here)
developers working together can override ext components "v1.1.1" and pick whatever 1.1.2-snapshot to use" - need to see how teams use the staging/snapshot version

fully validated 

- teams only have visibility on changes marked in the manifest file - not "in-development" merges
- we will likely need to group commits under test (lack of resources) - developers will need to triage together a test set that marked (n) commits in a timeframe as breaking CD