• The goal of the Functionality Freeze is to mark the end of adding functionality in the Release.
• After Functionality Freeze, no new visible functionality is to be added to the current ONAP release.
• The API definition development activities is over and a stable document describing the API is documented and available to the community.
• At Functionality Freeze, the following activities have been achieved:
  • All committed functionalities have been coded.
  • All Test Cases covering the scope of the release are defined (Project Team).
  • All Test Cases acceptance criteria are defined (Project Team).
  • All code have automated unit test (Project Team).
  • The team is using the complete Linux Foundation environment (build, Jenkins, Gerrit, FOSS, Automated Unit Test, Nexus).
  • A defined and documented final list of externally consumable APIs is available.
  • All vendors equipments have been delivered (Integration team)

To Pass Functionality Freeze, the PTL must:

1. Fill out in project space the Deliverables for Functionality Freeze Milestone Template template
2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

After Functionality Freeze is passed, the team focus on:

• Test Cases:
  
  • Automate and execute the Feature test.
  • Prioritize defects and address at least all critical and blocking defects.

• The goal of the API Freeze is to ensure API and Data Model are Frozen.
• At API Freeze, API stubs must be in implemented.
• All provisional APIs are at least functional if not yet fully tested.
  
• At Functionality Freeze, the following activities have been achieved:
  
  • All externally accessible APIs & data models may not be modified. An API exception process will allow for critical changes to APIs after API Freeze.
  • Any Changes to the API must be brought to the knowledge of the TSC for review and approval. APIs include, but are not limited to, all Java classes/interfaces declared public, all YANG models, all TOSCA profiles, all config file YANG schemas, and all REST/RESTCONF calls including the full URL with options.
  • 50% of Test Cases are automated (Project Team).
  • Issues brought to TSC or Architecture Coordinator.

Prior to Architecture review, Project teams must also review APIs with the TSC or Architecture Coordinator.

To pass Architecture review, the PTL must:

1. Fill out in project space the Deliverables for API Freeze Milestone Template template
2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverable

• The goal of the Release Sign-Off review is to ensure that:
  • The project has successfully passed all previous reviews.
  • All committed deliverables are available and reached expected quality criteria.
  • All testing activities are complete and successful.
  • All documentation activities are complete and available.
  • All Training Materials are complete and available.
  • All blocking issues have been successfully addressed (otherwise there is no reason to hold the review).
• These above statements are the conditions for the release to be included in the ONAP target release.
• TSC formally provides its disposition.

1. Fill out in their Project Space the Deliverables for Release Sign-Off Milestone Template template
2. Inform the TSC Chair and the Release Manager prior to the milestone on the availability of the deliverables