Independent Versioning and Release Process
Consumed API from other projects
| Project | API Dependency | Notes | |||
|---|---|---|---|---|---|
| Portal | 2.1.0 | When portal team releases we will upgrade. | |||
| AAF | v1.0.0 - ?? | Waiting for AAF team to release their artifacts | |||
| Dmaap | v1.1.3 | Dmaap | Linking directly to github Open Source version from R0 | Unable to upgrade to re-packaged client libraries in ONAP due to time considerations via blocker B24 | |
| AAI | v11 | No direct link to any libraries | |||
| APP-C | No direct link to any libraries | ||||
| SO | No direct link to any libraries | ||||
| VFC | No direct link to any libraries |
...
| Project | API | Notes |
|---|---|---|
| CLAMP | 1.2.0 | |
| DCAE | n/a | Implemented own python API |
1. Follow the process as outlined here: Independent Versioning and Release Process. Policy repositories inherit from oparent so release jobs will fail if any SNAPSHOT artifact is referenced in the pom.xml's.
- Verify there are no SNAPSHOTs and we are up-to-date with other team's released artifacts.
- Send Helpdesk tickets to LF ONAP release engineering specifying the Jenkin's Job to release Java artifacts and then the docker images
- Update the Integration team manifest so public knows what released artifacts are available. Example gerrit review:
- Update the Demo team heat scripts so the automated External Lab Jobs work and the Integration team has the latest artifacts for testing. Example gerrit review:
- TODO: Update the OOM team K8S Helm Charts ???
2. For any new changes to be done post-Release. Then the we must update to the next SNAPSHOT version:
...