...
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:
...
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.
...
The diagram below has 2 Major releases. Theses are Named Release "1.0.0-AmsterdamONAP" and "2.0.0-BeijingONAP".
1.0.0-Amsterdam ONAP is a Major Release, and embeds (in this example) 2 Artifact Release, "AAI Docker" version 1.0.0 and "AAF Docker" version 2.0.0.
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.
Example: 1 Major, 1 Service and 1 Enhancement Releases
...
The diagram below has 3 Named Releases (delivered chronologically in that order):
- 1.0.0-AmsterdamONAP
- 1.0.1-AmsterdamONAP
- 1.1.0-AmsterdamONAP
1.0.0-Amsterdam ONAP is a Major Release.
1.0.1-Amsterdam ONAP is a Service Release and is released to deliver (for example) a security issue in "AAI cpt 1" component. Note the third digit is now "4".
1.1.0-Amsterdam ONAP is an Enhancement Release and is released to deliver (for example) a backward compatible functionality in "AAF cpt 1" and "AAF cpt 2" components. Note the second digits are now "1" and "7". Note also there is no version continuity in "AAF cpt 2" between the Service (4) and the Enhancement (7) Releases. This is acceptable as the team may have delivered intermediate "Artifact Release" that were not embedded with a "Named Release".
Semantic Versioning
...
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.
Now things happen and we may need to deliver a hot fix (also called patch) into the latest available Release.
To perform the patch delivery, we simply perform the hot fix in the delivery branch, and tag it (1.0.1-AmsterdamONAP).
Once the hot fix is delivered (and everyone is back to happiness), we will decide how to carry over the changes into the current Release branch (Beijing branch on the case below). Most probably cherry pick technique will apply.
It may also happen that we need to carry over into the latest available Release (Amsterdam) some fixes or new backward functionalities that were discovered while developing current Release (Beijing). Here too, we will decide on the best options to carry over changes into the current available Release (Amsterdam) and Release and make a new Release (1.1.0-AmsterdamONAP).
As a guiding principle, the ONAP community keeps its focus on developing in Master branch. Hot fix process will be more the exception than the rule.
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
For the API versioning strategy, refer to: ONAP API Common Versioning
...
While this addresses a few of the questions below, some thought is required in the relation to a releaseThis requires some more thought. Questions to answer:
- 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
...