ODL Root Parent: Beryllium: Release Plan

Contents

Introduction

Release Deliverables

Release Milestones

• Offset:0

Externally Consumable APIs

• Please list and describe all externally consumable APIs or point to a document that does so.
• This need not be a list of all java interfaces and yang files, but should be a list of high-level functionality, e.g., flow programming.
  • For each such API, there should be a list of the bundles providing the API, but not necessarily the implementation.
• Each PROVISIONAL or TENTATIVE API must be listed as project deliverable
  • Must be declared as "IN" or "OUT" at the M3 Milestone

Expected Dependencies on Other Projects

Expected Incompatibilities with Other Projects

Please note any known or expected incompatibilities with other projects. For example, the different projects providing Neutron APIs have historically been incompatible with each other. For each incompatibility:

1. Note which expected features are incompatible if known
   1. Why
   2. Whether discussions occurred with the projects of the incompatible features as to how to become compatible.
      1. The results of those discussion.

If the incompatibility is expected, but the features are not yet know, please provide as much as is known or expected.

Projects are encouraged to engage with other projects to discuss and explore ways this incompatibility can be avoided either during this release or in a future release.

Compatibility with Previous Releases

Removed APIs and/or Functionality

• Please include list of a APIs and/or functionality that existed the previous release and will be removed.
  • For each such API/functionality, discuss any suggestions for how those who are using it should adapt.
  • In order for an API/functionality to be removed, it must have been deprecated in a previous release.
    • Functionality and/or APIs that were correctly tagged with the @Deprecated annotation in Java before the Lithium release can be considered deprecated and thus removed in Beryllium.

Deprecated APIs and/or Functionality

• Please include list of a APIs and/or functionality that existed the previous release and will be deprecated.
  • For each such API/functionality, discuss any suggestions for how those who are using it should adapt.
  • If possible, e.g., for all human-generated Java, add the @Deprecated annotation
  • If not possible, please note clearly things which are deprecated in a clearly visible manner

Changed APIs and/or Functionality

• Please include list of a APIs and/or functionality that existed the previous release and will be changed.
  • For each such API/functionality, provide guidance about who will be affected and how they should adapt.
  • In general, project's should strive to be backward compatible with the previous release and note what functionality will be removed by deprecating it and noting that with the @Deprecated annotations wherever possible.

Themes and Priorities

Requests from Other Projects

For each API request, the requesting project should create an entry like the example below.

After creating the entry, the requesting project should send an e-mail to release@lists.opendaylight.org, and both projects' dev lists using this template:

Subject: [REQUEST FOR NEW OR EXTENDED API] ${API name}

Note: This email is a request from ${requesting project} for a new or
extended API in ${providing project}.

API Name: ${API name}
Request: ${link to the request in the providing project's release plan}

Please let us know if you will be able to provide this new
functionality by the listed milestone. If you need clarifications or
help in providing the API, let us know so we can reach an agreement.

If you feel that providing this API is a bad idea regardless of where
the resources are coming from, please let us know why and ideally,
suggest and alternative.

Example Request

• Requesting Project:
• Providing Project: <should be this project, i.e., the project whose release plan this page is>
• Requested Deliverable Name:
• Needed Milestone: <e.g., M3, assumed to be at that milestone at the offset of the providing project unless otherwise stated>
• Requested Deliverable Description: <description of the change or new API needed>
• Response: <one of Yes, No, Tentative>
  • Description: <provides details of the response, e.g., "Yes, we can do that", "No, that's a bad idea", "No, we don't have the staff", "Tentaive, it's a good idea, but we don't know if we can">
  • Resources From: <should be either the providing project if they agree to do the work or the requesting project if the agree>
  • Link to Section in Requesting Project Release Plan: <if No or Tentative, link to the adjustments in the requesting project's release plan>
  • Link to Section in Providing Project Release Plan: <if Yes or Tentative, link to the deliverable in this release plan>
• Negotiation:
  • <this should be a back and fort until a response of Yes, No, or Tentative is reached>
  • <it should probably start with a response from the providing project that can be one of Yes, No, or Tentative, OR asking for clarification>
  • <after that it should go back and forth reaching a conclusion and then documented in the Response and Description above>
  • <if the negotiation fails or stalls, the TSC will do it's best to help>

Test Tools Requirements

• Please specify if the project will run System Test (ST) inside OpenDaylight cloud
• In case affirmative please enumerate any test tool (mininet, etc...) you think will be required for testing your project
  • The goal is to start test tools installation in rackspace as soon as possible
• In case negative be aware you will be required to provide System Test (ST) reports upon any release creation (weekly Release, Release Candidate, Formal Release, etc...)

Other