Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Introduction
The purpose of this document is to describe the cadence, processes, milestones, and associated tasks used in the ONAP release cycle.
...
See Project Status and Release Planning for information
...
and schedule for specific releases.
Overview
ONAP releases typically happen twice per year at approximately 6 month intervals. Releases are named after major world cities in alphabetical order. See the Long Term Release Roadmap for a list of previous and future releases.
The current release process was developed by community volunteers and rolled out with the Honolulu release. Releases are administered and tracked by a release manager. Release status is discussed at the weekly PTL meeting.
Requirements
Requirements are submitted to the Requirements Subcommittee for evaluation in the weeks leading up to the M2 milestone. Requirements include specifications, features, use cases, best practices, global requirements, and Proof of Concept (PoC). These are described on the Requirement Types page.
Requirements are documented as epics in the REQ Jira project. These epics will then have release management tasks attached to them for each release milestone, which are the responsibility of the requirement owner to complete. In addition, for features, specifications, and use cases, the requirement owner will also attach one or more integration test tasks. The status of these test tasks is closely tracked from milestone M4 until the end of the release.
Time Based Releases
As of the Honolulu release, ONAP releases are time based. This means that requirements are evaluated at M4 for readiness for integration testing. Those that are ready proceed with the release. Those that are not ready are deferred to the following release.
Release Management Tasks
In order to track release status, release management tasks are assigned to ONAP projects and to requirement owners using Jira. Release management tasks for projects are assigned using the project team's own Jira project. Release management tasks for requirement owners are attached to the requirement epic in the REQ project. Release status at each milestone is determined largely based on the status of the release management tasks.
Exception Process
If a release milestone, best practice, or general requirement cannot be met, then the project team or requirement owner may file an exception request. Exception requests may be prepared using the exception request page contained within the project status area for each release. Exception requests are periodically reviewed by the TSC.
Release Milestones
| Info |
|---|
| Note: Project tasks UPDATED to reflect the task review performed by the PTLs in 1H23 and approved by the TSC. |
As mentioned above, release milestones, and their associated tasks, are used to track the status of the release. The milestones and management tasks used in the current release process are described in the table below.
| Milestone | Description | Project Tasks | Requirement Owner Tasks | Subcommittee Tasks |
|---|---|---|---|---|
| M0 | Start of release cycle | |||
| M1 | General requirements approved |
...
...
|
|
...
| ||
| M2 | Specification freeze
|
|
...
|
| |||
| M3 | Final Code Submission |
| None | |
| M4 | Feature freeze |
|
...
|
...
|
|
...
| RC | Release Candidate 0 Integration and Test |
|
...
|
...
|
|
...
| DRAFT: Need to discuss with Arch Subcommittee
| |||
| Sign Off | Approval for release by the TSC |
|
|
| Table of Contents |
|---|