Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Key Contacts - Byung-Woo Jun  (Ericsson)


Note: The ONAP Streamlining - The Process has been approved by ONAP TSC


ONAP Benefits to the Industry

...

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment dependenciesevolution 


ONAP Helm Charts Dependencies (by Andreas Geissler)

...

  • ONAP supports clustering components by use cases:
    • Selection of the best components for a particular task in systems
    • Responsive integration and delivery
    • ONAP still can provide reference automation for coordination
  • ONAP E2E integration testing can be performed for code quality.
  • Focused Integration testing can be performed, based on use cases.
  • Additional analysis will be provided as needed.


Release Management

...

Tasks 

  • Marketing version, Montreal, will be scheduled as the previous releases.
  • Setting release schedule plans for Montreal
  • The Marketing version will be used as the Major version by ONAP projects
  • PTLs decide the minor and patch versions, based on their project release cycles and share the project versioning with TSC
    • Provide each component release flexibility and evolution
  • Integration & Pair-wise testing
  • Integration testing will continue to increase ONAP project overall qualities
  • Pair-wise testing will continue but it will be based on use cases
  • Project testing will be performed by each project team
  • For Montreal, security scanning will continue as before
  • Based on feedback during the Montreal, the release plan can be revisited

Documentation Versioning Proposal

Montreal Release Plan Proposal

  • Each PTL determines their project agile cycle(s) based their features
  • PTLs/Feature owners coordinate with ARCCOM/REQCOM/SECCOM/TSC for the feature review and approval per agile iteration
  • PTLs/Feature owners may work with OOM, INT and DOC for build, testing and documentation, as needed
    • project release specific documentation should be handled in a automated fashion (e.g., scripts; PTLs create the release-specific rst and scripts put the rst contents into RTD)
  • Each agile iteration/sprint is reviewed and critiqued by the project team (and ARCCOM/REQCOM/SECCOM/INT/TSC as needed…) and is used to determine what the next step (PTL decides it) until RC
    • e.g., priorities, guidance, standards, security…
  • After Montreal, we may want to revisit the Marketing release RC and Sign off


Image Added


Documentation Versioning Proposal

...

References

...