About this Document


This was an intentionally a verbatim copy of sections from the Project Lifecycle & Releases Document which has the following to say about the Release Review Document:

Both the Release Plan and Release review document are intended to be relatively short, simple, posted publicly on the wiki documents to assist projects in coordinating among themselves, and the general world in gaining visibility.

Insofar as this has been changed, it has kept with in that spirit folding in our experience conducting release reviews.


When copying, please remove this entire “About this Document” section and simply fill out the next sections.


Please do not remove any sections. Also, short sentences are better than “n/a” or “none” as it is often confusing as to whether that means there are no issues or you simply didn’t think about or address anything.

Project Name

Major Features

For each top-level feature, identify the name, url, description, etc. User-facing features are used directly by end users. Remove this paragraph.

Feature Name


  • Installation Guide(s):

  • User Guide(s):

    • Link to Guide. Should be formatted something like:

      :ref:`Guide name <guide-label-name>`

      Where the <guide-label-name> is something like:

      .. _guide-label-name:
      Project User Guide

      As described in Cross-referencing arbitrary locations.

  • Developer Guide(s):

    • Link to Guide. Use same format as above.

Security Considerations

  • Do you have any external interfaces other than RESTCONF?
    • If so, how are they secure?
    • What port numbers do they use?
  • Other security issues?

Quality Assurance

  • Link to Sonar Report (Test coverage percent)
  • Link to CSIT Jobs
  • Other manual testing and QA information
  • Testing methodology. How extensive was it? What should be expected to work? What has not been tested as much?


  • Is it possible to migrate from the previous release? If so, how?


This is asking if somebody can move from an installation of the previous release while keeping data. This isn’t currently, natively supported in Opendaylight, so if it’s possible, it is because of some project-speicific work and instructions which should be explained here. Remove this note.


  • Is this release compatible with the previous release?
  • Any API changes?
  • Any configuration changes?

Bugs Fixed

  • List of bugs fixed since the previous release

Known Issues


  • List of features/APIs which are EOLed, deprecated, and/or removed in this release


  • List of standrads implemented and to what extent

Release Mechanics


We will also ask about your testing of the latest SR, but that should probably not formally be part of this document. Remove this note.