Target
Increase transparency on software modules (repositories) included in an ONAP release to enable effective and efficient ...
- security management
- release management
- documentation management
Provide reliable information for an ONAP release ...
- which software module (repository) is included (was used to build the docker container)
- which version of the software module is included (was used to build the docker container)
The above information must be managed ...
- from the start of the release process (planning phase)
- to the end of the release process
- building the deployable release
- building the release specific documenattion
To participate in a ONAP release, a software module ...
- must be in the 'maintained' state
- must have created a release branch
- must have updated their documentation to reflect the current state of development
- must have up-to-date release notes (on sub-project level or in the main project?)
Current Situation
- A deployable ONAP release consists of 'maintained' an 'unmaintained' software modules
- Only 'projects' are managed in the release process
- But a 'project' consists of 1-n repositories. Repositories are not managed in the release process.
- Only 'maintained' projects are managed in the release process.
- But "unmaintained" software modules (docker container) are added to the list of deployed software modules in the end of the release process