Objective

...

Issue of dependency on Snapshot

Example of the problem:

Imagine you have your cpt A build working fine. Your build is depending on cpt B SNAPSHOT build.

For some good reasons, cpt B makes a new build. As cpt A relies on B SNAPSHOT (meaning latest build) when you rebuild cpt A if the build breaks you will not know if the problem is within cpt A or within its dependency cpt B.

To address the Snapshot dependency scenario, the idea is to move away from Snapshot dependency to "Release Artifact" dependency only. The word "Release Artifact" is loaded with the sense that the build is stable, has been thoroughly tested and can be used by another team. The "Released Artifact" is available within the "Nexus Release"  repo repo (refer to Nexus section below for further description of Nexus repos). The PTLs and the project team decide on their own when to create a "Release Artifact". This approach allows to truly decouple the builds from each other and avoid the situation where something that was working fine before doesn't suddenly break due to snapshot changes.

...

In order to know whether you're depending on the right version of a particular artifact, ONAP will be maintaining a master "version manifest" for each named release (e.g. Amsterdam) specifying the version of each component that is to be delivered within a release.  The The manifest is a structured list of components and their versions. The manifest is intended to track a particular ONAP release and be used to track all versions of all components within a release. 

One early idea was to embed the version manifest within the oparent artifact, perhaps as version properties within the POM file that can be directly consumed by downstream POMs.  This This approach, however, has some issues:

Just think about this scenario:

cpt A version 2.3.0 depends on o-parent 0.9.0

cpt A releases 2.3.1, which still depends on o-parent 0.9.0

Now, cpt A version in o-parent needs to be updated

Due to the change of the cpt A version in o-parent, o-parent itself needs to be bumped to 0.9.1.  Now we have a circular dependency.

Each PTLs will need to update the manifest to declare the "Released" version available.  In order to avoid the circular dependency issue, any updates to the version manifest, must NOT require any artifact to be version bumped and re-released.  

...

Each project team decides on when version numbers of repos under it’s its control are incremented and artifacts are place in a Nexus Release repo. In particular the version numbers do not have to be in sync across projects and do not have to be aligned with the release version number.

...

Note that the Artifact Release have different version number and do embed components that also have different version mumbernumber.

The version number numbers are documented in the o-parent manifest.

Image RemovedImage Added

Example: 1 Major, 1 Service and 1 Enhancement Releases

...

To make this happens, we branch out from Master, create a delivery branch (Amsterdam, BiejingBeijing, Casablanca,...), and lock the delivery branch to strictly control what goes into delivery branch. Developers continue their non delivery branch work in Master. 
At the end of each Release, artifacts are tag in Gerrit, according to above versioning principles.

...

• Who assigns version numbers?
• same as for repos. Projects decide
• Where do we track available APIs for a given release ?
• -> we We need something that has a similar role to O-Parent
• What’s our policy of depreciating APIs? 
• -> I assume we would require MAJOR API versions to be available for extended periods of time

...