...
The activities of the ONAP community are articulated around projects and releases. The scope of each project is aligned with the ONAP architecture and the scope of each release is defined with the objective to fulfill a particular requirement(s) (use case(s, functional or non functional).
3.3.1.1. A project is a long term endeavor setup to deliver features across multiple releases, which have a shorter lifespan.
...
3.3.1.3. The key point of the project and release lifecycle process is are to provide adequate visibility to all stakeholders, provide synchronization, and support to all contributors.
3.3.1.4. This document covers the ONAP project lifecycle. The Release Lifecycle is documented in a separate document (include link when ready) Release Process.
3.3.2. Project Lifecycle Overview
3.3.2.1. The project lifecycle provides the freedom for each team to conduct its project according to their needs, culture and work habits. Thus, the project lifecycle is not prescriptive on how each project operates.
...
3.3.2.
...
2.
...
An ONAP release can be composed of 1 to N projects. As such the number of contributing projects to a particular release may vary overtime.
...
3.3.2.
...
3.
...
A release is initiated to deliver a set of project deliverables.
...
3.3.2.
...
4.
...
The project lifecycle process does not impose a duration for the project nor for the release. There is an independent Release Plan document for each release to specify release
...
timelines which includes, but is not limited to the following:
3.3.2.5. Release Plan
3.3.2.5.1. Introduction
3.3.2.5.2. Release Deliverables
3.3.2.5.3. Release Milestones
3.3.2.5.4. Expected Dependencies on Other Projects
3.3.2.5.5. Compatibility with Previous Release
3.3.2.5.6. Themes and Priorities
3.3.2.5.7. Other(s)
3.3.2.5.8. Features delivered
3.3.2.5.9. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.5.10. Architectural Issues (if any)
3.3.2.5.11. Security Issues (if any)
3.3.2.5.12. Quality Assurance (test coverage, etc)
3.3.2.5.13. End-of-life (API/Features EOLed in Release)
3.3.2.5.14. Summary of Outstanding Bugs
3.3.2.5.15. Summary of Standards Compliance
3.3.2.5.16. Delta between planned schedule and actual schedule
3.3.2.6. Release Review
The project shall document results of the review in the release notes
3.3.2.6.1. Features delivered
3.3.2.6.2. Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.2.6.3. Architectural Issues (if any)
3.3.2.6.4. Security Issues (if any)
3.3.7.6.5. Quality Assurance (test coverage, etc)
3.3.2.6.6. End-of-life (API/Features EOLed in Release)
3.3.2.6.7. Summary of Outstanding Bugs
3.3.2.6.8. Summary of Standards Compliance
3.3.2.6.9. Delta between planned schedule and actual schedule
3.3.3. Project Lifecycle States and Reviews
ONAP project lifecycle defines six states that each project goes through. The project lifecycle may extend across multiple releases.
The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.
In order to effectively review project progress, fivereviews are build-in within the project lifecycle.
The lifecycle of a project is depicted on the following diagram:
Project State | Description |
Proposal | Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs. |
Incubation | Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) |
3.3.3. Project Lifecycle States and Reviews
ONAP project lifecycle defines five states that each project goes through. The project lifecycle may extend across multiple releases.
3.3.3.1. The procedure of moving from one state to the next one is independent from the release and the pace depends on each individual project.
...
3.3.3.3. The lifecycle of a project is depicted on the following diagram:
Project State | Description |
Proposal | Project doesn’t really exist yet, may not have real resources, but is proposed and is expected to be created due to business needs. |
Incubation | Project has resources, but is recognized to be in the early stages of development. The outcome is a minimum viable product (MVP) that demonstrates the value of the project and is a useful vehicle for collecting feedback, but is not expected to be used in production environments. |
Mature | Project is fully functioning and stable, has achieved successful releases. It should also be noted that Projects in Mature state meet all Global Requirements. |
Core | Project provides value to and receives interest from a broad audience. It should also be noted that Projects in Mature state meet all Global Requirements. |
Archived | Project can reach the Archived state for multiple reasons. Either the project has successfully been completed and its artifacts provide business values, or the project has been cancelled for unforeseen reasons (no value anymore, technical, etc.). Project in any state can be Archived through a Termination Review. |
| Unmaintained |
|
...
From State | To State | Review Description |
Null | Proposal | |
Proposal | Incubation | Incubation review |
Incubation | Mature | Maturity review |
Mature | Core | Core review |
Core | Archived | Termination review |
| Any(except Null)Incubation/Mature/Core | Unmaintained | Unmaintained review |
| Unmaintained | Incubation, Mature, Core, ArchivedCorresponding /Mature/Archived | Incubation/Mature/Archived review see: Project State: Unmaintained State review(e.g:Incubation review, Mature review) |
Note 1: Project proposals are posted in the “Proposed Projects” section of the ONAP wiki. Approved projects are posted to the “Approved Projects” section of the ONAP wiki.
...
A project’s release cycle may be tailored by allowing some exceptions to the normal release process. Tailoring may be initiated in two in three ways:
3.3.4.1. By the TSC voting members: TSC voting members reserves the right to allow changes to the process in order to meet criteria that were initially unknown.
...
3.3.4.3. Tailoring practices will be documented as we progress through our releases. The TSC should respond to requests in a timely manner.
3.3.5. Reviews & Metrics Overview
...
3.3.5.2.6. During Release Kick-Off, the project team may request that the TSC conduct a review to move up the ladder.
3.3.6. Project Reviews
...
3.3.6.2.4.4. Mature artifacts produced: The project demonstrates that the artifacts produced by the project are deployable (where applicable) and have been successfully deployed, configured and used by end users (typically, service providers).
...
).
3.3.6.3. Core Review
The goal of the Core Review is to ensure:
3.3.6.3.1. Artifacts for Maturity State are complete and accepted
3.3.6.3.2. Plan for Core State are accepted. For the Core Review
...
it is expected to deliver a comprehensive integration plan
3.3.6.3.3. Once a project has passed The goal of the Core Review is to ensure:, the project is in Core State and may span over multiple releases.
3.3.6.3.14. Artifacts for Maturity State are complete and acceptedReview metrics for Core review include the metrics for maturity review plus the following:
3.3.6.3.2. Plan for Core State are accepted. For the Core Review it is expected to deliver a comprehensive integration plan.3.5. Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least three different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in ONAP Code Review and/or in the review-tool of the target upstream project(s).
3.3.6.3.36. Once a project has passed the Core Review, the project is in Core State and may span over multiple releases. 3.3.6.3.4. Review metrics for Core review include the metrics for maturity review plus the following:Recognized value through other projects: The project demonstrates that its results are leveraged by other ONAP projects in an ongoing way, i.e. for at least the last two releases.
3.3.6.3.57. Contributor diversity: The project demonstrates that it has a stable core team of contributors/committers which are affiliated to a set of at least three different companies. Core team members are those who have been active on the project for more than two releases, which means they were reviewing contributions to the project in ONAP Code Review and/or in the review-tool of the target upstream project(s)Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the ONAP-O CI/CD test pipeline, and that tests bear successful results.
3.3.6.3.6. Recognized value through other projects: The project demonstrates that its results are leveraged by other ONAP projects in an ongoing way, i.e. for at least the last two releases.8. Stability, Security, Scalability and Performance levels have reached a high bar and are maintained as such for each release.
3.3.6.4. Termination Review ← Pick up the discussion on the specific wording of "termination" here on
A bounded piece of work is complete, no new features are being added, but there are still individuals around to maintain the code for bug and security fixes.
The goal of the Termination Review is to ensure that:
3.3.6.34.7. Successful integration tests (only applicable to projects which provide features/functionality): The project demonstrates that component tests and system-level tests have been implemented, that tests are used within the ONAP-O CI/CD test pipeline, and that tests bear successful results.1. Artifacts for Core state are complete and accepted
3.3.6.4.2. Core project artifacts are acceptable and meet the acceptance criteria
3.3.6.4.3.8. Stability, Security, Scalability and Performance levels have reached a high bar.
...
. Project Team has the confidence that its artifacts can be used outside the ONAP community
3.3.6.4.4. Metrics for Termination review are available
3.3.6.5. Unmaintained Review
An unmaintained review is automatically triggered when bounded piece of work has had no individuals available or willing to contribute or participate in bug or security fixes in at least two releases.
The goal of the Termination Unmaintained Review is to ensure that:
3.3.6.45.1. Artifacts for Core state are complete and acceptedProject(s) or sub-project(s) is no more longer part of any official release
3.3.6.4.2. Core project artifacts are acceptable and meet the acceptance criteria.5.2. These Project(s) or sub-project(s) are no more subject to longer compliant with non-functional compliances, but are still in OOM.
3.3.6.45.3. Project Team has the confidence that its artifacts can be used outside the ONAP community 3.3.6.4.4. Metrics for Termination review are available The project will be still part of OOM deployment and High Priority bugs might be fixed
The process of managing this review state can be found here
3.3.7. Mature Release Process
A Project’s Committers make all decisions about Releases of that Project. However However, to be eligible to be considered ‘Mature’, the project must demonstrate a history of following the Mature Release Process. The The purpose of the Mature Release Process is to ensure openness and maximum opportunity for participation. The The idea is to have a simple, clear, public declaration of what a project intends to do and when, and what was actually done in a release cycle. Towards Towards that end, a project following the ‘Mature Release Process’ should have a Release Plan published at the beginning of its release cycle by its committers, and a Release Review just prior to the project release.
Both Release Plan and Release Review documents are intended to be relatively short, simple, and posted publicly on the wiki to assist the project in coordinating among themselves and the general world in gaining visibility.
These should contain roughly the following sections:
3.3.7.1. Release Plan
3.3.7.1.1. Introduction Introduction
3.3.7.1.2. Release Release Deliverables
3.3.7.1.3. Release Release Milestones
3.3.7.1.4. Expected Expected Dependencies on Other Projects
3.3.7.1.5. Compatibility Compatibility with Previous Release
3.3.7.1.6. Themes Themes and Priorities
3.3.7.1.7. Other Other
3.3.7.1.8. Features Features delivered
3.3.7.1.9. Non Non-Code Aspects (user docs, examples, tutorials, articles)
3.3.7.1.10. Architectural Architectural Issues (if any)
3.3.7.1.11. Security Security Issues (if any)
3.3.7.1.12. Quality Quality Assurance (test coverage, etc etc)
3.3.7.1.13. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.1.14. Summary Summary of Outstanding Bugs
3.3.7.1.15. Summary Summary of Standards Compliance
3.3.7.1.16. Delta Delta between planned schedule and actual schedule
3.3.7.2. Release Review
3.3.7.2.1. Features Features delivered
3.3.7.2.2. Non Non-Code Aspects (user docs, examples, tutorials, articles articles)\
3.3.7.2.3. Architectural Architectural Issues (if any)
3.3.7.2.4. Security Security Issues (if any)
3.3.7.2.5. Quality Quality Assurance (test coverage, etc etc)
3.3.7.2.6. End End-of-life (API/Features EOLed in Features EOLed in Release)
3.3.7.2.7. Summary Summary of Outstanding Bugs
3.3.7.2.8. Summary Summary of Standards Compliance
3.3.7.2.9. Delta Delta between planned schedule and actual schedule