...
- Minimize work and complexity for project teams
- Provide an easy to use configuration to ONAP users and the integration team
- Be intuitive
ONAP Versioning Strategy
What
...
are the 2 big
...
issues to address?
ONAP is composed of more than 30 projects and 200 repositories. Dealing with snapshot components dependencies and documenting the version tree for each build can become a Dantesque activity.
Just thing about this case:
Assumption: The dependency tree is documented in o-parent.
cptA version 2.3.0 depends on o-parent 0.9.0
For some reasons cptA makes another build and now becomes version 2.3.1. So, to take into account that fact o-parent needs to be bumped to 0.9.1.
Now, the nightmare starts. As we have a new o-parent 0.9.1, it requires all other artifacts to be version bumped, rebuilt and re-released. And there we go for a big mage re-build all ONAP.
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 build.
For good some reasons, cpt B makes a new build. As cpt A relies on Snapshot (meaning latest build) when you rebuild cpt A if the build beaks 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 ArtifactTo avoid the nightmare scenario, ONAP is adopting an approach where dependencies rely only on "Released" artifacts. The word "Released" is loaded with the sense that the build is stable, has been thoroughly tested and can be used by another team. The "Released Artifact" artifact is available within the "Nexus Release" stage (refer to Nexus section below for further description of Nexus stages). 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.
The "Release Artifact" dependency also address the fact that "mega build" are no longer necessary.
Issue of identifying which version you depend on
ONAP is composed of more than 30 projects and 200 repositories. Dealing with snapshot components dependencies and documenting the version tree for each build can become a Dantesque activity.
Just thing 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.
Understanding the above, ONAP is maintaining Understanding the above, do we still need a place to document the dependency tree? The answer is yes, o-parent will maintain a manifest of "Released Artifacts" artifacts. The o-parent manifest is a structured dependency tree and is NOT used for builds. The o-parent list of components and their version. The manifest is intended to track a particular ONAP release and be used to track all versions of all components within a release. The o-parent manifest must NOT be used to track versions each time there is a new build.
Each project teams will need to update the o-parent manifest to declare the "Released" version available.
To avoid above scenario, ONAP has decided the manifest is not part of any artifact binary. However, the manifest is still in source control. A specific version of this manifest will be blessed by TSC and make the "Named Released" (see definition of "Named Release" below).
Nexus
ONAP is using Nexus in 3 stages:
...