...
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 activitiesactivity.
Just thing about this case:
...
cptA version 2.3.0 depends on o-parent 0.9.0
For some reasons cptA make makes another build and now has a 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. We As we have a new o-parent 0.9.1 that , 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.
To avoid the nightmare scenario, ONAP is adopting a "Staging" 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 is available within the '"Nexus Release" stage (refer to Nexus section below for further description of Nexus stages). 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.
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. The o-parent manifest is a structured dependency tree and is NOT used for builds. The o-parent 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 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.
...