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 (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.

...

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 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.  

...

After the delivery branch is created, we will have a very short delivery team to control the final content of the Release. The delivery Team composed of 1 member representing each project will analyze the impact of every defect and decide its inclusion or not into the delivery release. Jira will be used to support all documentation and decisions.
The Gerrit merge process will be limited to the delivery team.

API Versioning

This requires some more thoughtFor the API versioning strategy, refer to: ONAP API Common Versioning Strategy (CVS) Guidelines 

While this addresses a few of the questions below, some thought is required in the relation to a release. Questions to answer:

• Who assigns version numbers?
• same as for repos. Projects decide
• Where do we track available APIs for a given release ?
• -> 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

...