Skip to end of metadata
Go to start of metadata

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 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 and global requirements. 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 RC1 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

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.

MilestoneDescriptionProject TasksRequirement Owner Tasks
M0Start of release cycle

M1General requirements approved
  • Review Code Coverage goal vs. actuals
  • Update the FOSS (Free and Open Source Software) wiki page (Project FOSS → Project)
  • Request an architectural subcommittee review
  • Document API issues in the requirement description
  • DOCS:  create documentation tracking page and pre-fill information.
M2

Specification freeze

  • Freeze the scope
  • Review approved Global Requirements
  • Verify that specifications and features are approved by affected projects
  • PTLs determine impact of features and specs on APIs
  • Complete release planning template
  • Verify information in documentation tracking page.  Update as necessary.
  • Update documented risks
  • Review license scan issues
  • Complete Architectural subcommittee review
  • Data models shared with Modeling subcommittee
  • Verify that there are no merge requests older than 36 hours
  • Communicate API changes to other projects
  • Finalize documentation of API changes and share with affected PTLs
M3Final Code Submission
  • Verify that test coverage goals have been met
  • Resolve all Global Requirement impacts
  • Verify that there are no merge requests older than 36 hours
  • Review license scan issues
  • Resolve high/highest priority JIRA issues
None
M4Feature freeze
  • Start OOM review with updated container image
  • Assign Jira issues to the release
  • Complete preliminary documentation
  • Review and update INFO.yaml
  • Update integration weather board
  • Update Release Platform Maturity and CII badging
  • Resolve high/highest priority JIRA issues
  • Update the FOSS wiki page
  • Verify that there are no merge requests older than 36 hours
  • Review license scan issues
  • DOCS:   confirm that PTL repo changes in M2 (new/removed repos) and M4 (preliminary doc) are represented in master and RTD
  • Document integration test tasks in Jira
  • Complete preliminary documentation
  • Review and update scope status
RC0Release Candidate 0 Integration and Test
  • Create a release branch
  • Complete marketing update
  • Update integration weather board and create pairwise testing page
  • Resolve high/highest priority JIRA issues
  • Deliver updated container to integration team
  • Complete project testing
  • Review license scan issues
  • Update RC0 scorecard field
  • Update integration test tasks in Jira
  • Complete marketing update page
RC1Release Candidate 1 Integration and Test
  • Create preliminary release notes
  • Review license scan issues
  • Verify readiness of release artifacts
  • JIRA Cleanup
  • Create preliminary release notes
  • Complete 50%of  E2E testing
RC2Release Candidate 1 Integration and Test
  • JIRA Cleanup
  • Verify readiness of release artifacts
  • Finalize documentation
  • DOCS: verify that repo branch exists, verify that RTD branch exists, verify that project release notes have been finalized
  • Complete E2E testing
  • JIRA cleanup
  • Finalize Use Case, Specification, and Feature documentation, including release notes
Sign OffApproval for release by the TSCTBDTBD

  • No labels

1 Comment

  1. The previous, outdated version of the ONAP Release Process can be found here.