DRAFT under
...
editing
Objective
The goal of the ONAP versioning strategy is to provide a compromise addressing the following competing goals:
...
Imagine you have your cpt A build working fine. Your build is depending on cpt B SNAPSHOT build.
For good some good reasons, cpt B makes a new build. As cpt A relies on Snapshot B SNAPSHOT (meaning latest build) when you rebuild cpt A if the build beaks breaks you will not know if the problem is within cpt A or within its dependency cpt B.
...
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.
In order 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 that version of each component that is to be delivered with that release. 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 approach, however, has some issues:
Just think Just thing about this scenario:
cpt A version 2.3.0 depends on o-parent 0.9.0
...
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 project teams 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, in and or itself, must NOT require any artifact to be version bumped and re-released.
Understanding the above, ONAP is maintaining a manifest of "Released Artifacts" outside the build process and outside of any binary artifacts. HoweverTo 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 used to make the "Named ReleasedRelease" (see definition of "Named Release" below).
...