+.. _managed-release:
+
***************
Managed Release
***************
---------------------------
The Managed Release Model will reduce the overhead both on projects taking
-part in the Managed Release and Unmanaged Projects.
+part in the Managed Release and Self-Managed Projects.
Managed Projects will have fewer, smaller checkpoints consisting of only
information that is maximally helpful for driving the release process. Much of
that can break the jobs they depend on will be a smaller set, more stable and
more responsive.
-Projects that are Unmanaged will have less overhead and reporting. They will
+Projects that are Self-Managed will have less overhead and reporting. They will
be free to develop in their own way, providing their artifacts to include in
the final release or choosing to release on their own schedule. They will not
be required to submit any checkpoints and will not be expected to work closely
latitude to step in and help projects that are required for dependency reasons
but may not have a large set of active contributors.
+.. _managed-projects:
+
Managed Projects
================
For implementation reasons, the projects that are able to release independently
must depend only on other projects that release independently. Therefore the
Release Integrated Projects will form a tree starting from odlparent. Currently
-odlparent and yangtools are the only Release Integrated Projects, but others
-may join them in the future.
+the following projects are Release Integrated:
+
+* aaa
+* controller
+* infrautils
+* mdsal
+* netconf
+* odlparent
+* yangtools
Requirements for Managed Projects
---------------------------------
Managed Projects should only depend on other Managed Projects.
-If a project wants to be Managed but depends on Unmanaged Projects, they
+If a project wants to be Managed but depends on Self-Managed Projects, they
should work with their dependencies to become Managed at the same time or
-drop any Unmanaged dependencies.
+drop any Self-Managed dependencies.
Documentation
+++++++++++++
for external communication, such as marketing to users or a report to
other LFN projects or the LFN Board.
-* If a project is transitioning from Unmanaged to Managed or applying for
+* If a project is transitioning from Self-Managed to Managed or applying for
the first time into a Managed release, raise a Jira **Project Plan** issue
against the TSC project highlighting the request.
* Select the release version in the **ODL Release** field
- * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL Participation**
+ * Select the ``NOT_Integrated (Self-Managed)`` value in the **ODL Participation**
field
* Select the appropriate value in the **ODL New Participation** field:
.. code-block:: none
Summary
- This is an example of a request for a project to move from Unmanaged to
- Managed. It should be submitted no later than the start of the release.
- The request should make it clear that the requesting project meets all
- of the Managed Release Requirements.
+ This is an example of a request for a project to move from Self-Managed
+ to Managed. It should be submitted no later than the start of the
+ release. The request should make it clear that the requesting project
+ meets all of the Managed Release Requirements.
Healthy Community
The request should make it clear that the requesting project has a
may also show that the project has a history of dealing with CLM
violations in a timely manner.
-* If a project is transitioning from Managed to Unmanaged, raise a Jira
+* If a project is transitioning from Managed to Self-Managed, raise a Jira
**Project Plan** issue against the TSC project highlighting the request.
* Select your project in the **ODL Project** field
* Select the appropriate value in the **ODL Participation** field:
``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
- * Select the ``NOT_Integrated (Unmanaged)`` value in the
+ * Select the ``NOT_Integrated (Self-Managed)`` value in the
**ODL New Participation** field
* In the **Summary** field, put something like:
- ``Project-X Fluorine Joining/Moving to Unmanged for Fluorine``
+ ``Project-X Fluorine Joining/Moving to Self-Manged for Fluorine``
* In the **Description** field, fill in the details:
.. code-block:: none
- This is a request for a project to move from Unmanged to Managed. It
+ This is a request for a project to move from Managed to Self-Managed. It
should be submitted no later than the start of the release. The request
does not require any additional information, but it may be helpful for
the requesting project to provide some background and their reasoning.
* Number of reviews per-reviewer.
* Grievances raised against the project since the start of the release.
+
+Service Release Code Freeze
+-------------------------------------------------------------
+
+There will be an additional checkpoint for Service Releases, where code will
+freeze one week before the schedule release. Here are more details:
+
+* After code-freeze, the specific branch will be locked down, just like with
+ a major release.
+
+* Once the branch is locked, only fixes for blocker bugs will be allowed
+ as long as they are approved by TSC and Release PM.
+
+* Bugs or Regression discovered during RC test will also be considered by
+ Release PM.
+
+* Release PM will track and allow those fixes that have not been reviewed
+ or merged because of project low activity or lack of committers. The
+ deadline to communicate the list of patches waiting review for a
+ particular Service Release is the code freeze date.
+
Managed Release Integrated Release Process
------------------------------------------
cover everything they expect to do in the next Managed Release, which may
encompass any number of major version bumps for the MRI Projects.
-Moving a Project from Unmanaged to Managed
-------------------------------------------
+Moving a Project from Self-Managed to Managed
+---------------------------------------------
-Unmanaged Projects can request to become Managed by submitting a
+Self-Managed Projects can request to become Managed by submitting a
**Project_Plan** issue to the TSC project in Jira. See details as described
under the `Initial Checkpoint`_ section above. Requests should be submitted
before the start of a release. The requesting project should make it clear that
* odlparent
* yangtools
-Unmanaged Projects
-==================
+Self-Managed Projects
+=====================
-Requirements for Unmanaged Projects
------------------------------------
+In general there are two types of Self-Managed (SM) projects:
+
+#. Self-Managed projects that want to participate in the formal (major or
+ service) OpenDaylight release distribution. This section includes the
+ requirements and release process for these projects.
+
+#. Self-Managed projects that want to manage their own release schedule
+ or provide their release distribution and installation instructions
+ by the time of the release. There are no specific requirements for
+ these projects.
+
+Requirements for SM projects participating in the release distribution
+----------------------------------------------------------------------
+
+Use of SNAPSHOT versions
+++++++++++++++++++++++++
+
+Self-Managed Projects can consume whichever version of their upstream dependencies
+they want during most of the release cycle, but if they want to be included in the
+formal (major or service) release distribution they must have their upstream
+versions bumped to SNAPSHOT and build successfully no later than one week before
+the first Managed release candidate (RC) is created. Since bumping and integrating
+with upstream takes time, it is strongly recommended Self-Managed projects start
+this work early enough. This is no later than the middle checkpoint if they want
+to be in a major release, or by the previous release if they want to be in a
+service release (e.g. by the major release date if they want to be in SR1).
+
+.. note:: To help with the integration effort, the `Weather Page`_ includes API and
+ other important changes during the release cycle. After the formal release,
+ the release notes also include this information.
+
+Add to Common Distribution
+++++++++++++++++++++++++++
+
+In order to be included in the formal (major or service) release distribution,
+Self-Managed Projects must be in the common distribution pom.xml file and the
+distribution sanity test (see :ref:`add-proj-dist`) no later than one week before
+the first Managed release candidate (RC) is created. Projects should only be added
+to the final distribution pom.xml after they have succesfully published artifacts
+using upstream SNAPSHOTs. See `Use of SNAPSHOT versions`_.
+
+.. note:: It is very important Self-Managed projects do not miss the deadlines for
+ upstream integration and final distribution check, otherwise there are
+ high chances for missing the formal release distribution. See
+ `Release the project artifacts`_.
+
+Cut Stable Branch
++++++++++++++++++
-Unmanaged Project requirements are designed to be as low-overhead as possible
-while still allowing for participation in the final release. If Unmanaged
-Projects do not want to participate in the final release and instead provide
-their artifacts to their consumers through another channel, there are no
-requirements.
+Self-Managed projects wanting to use the existing release job to release their
+artifacts (see `Release the project artifacts`_) must have an stable branch in
+the major release (fluorine, neon, etc) they are targeting. It is highly recommended
+to cut the stable branch before the first Managed release candidate (RC) is created.
-SNAPSHOT Versions by Release
-++++++++++++++++++++++++++++
+After creating the stable branch Self-Managed projects should:
-Unmanaged Projects can consume whichever version of their upstream dependencies
-they want during most of the release cycle, but if they want to be included in
-the final release distribution they must bump their versions to SNAPSHOT no
-later than one week before code freeze.
+* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in master
+ will not interfere with the new created stable branch artifacts.
-Jobs Required for Unmanaged Projects Running
-++++++++++++++++++++++++++++++++++++++++++++
+* Update .gitreview for stable branch: change defaultbranch=master to stable branch.
+ This way folks running "git review" will get the right branch.
-Unmanaged Projects that wish to take part in the final release must enable the
-validate-autorelease job. Unmanaged Projects can release artifacts at any time
-using the release job. To take part in the final release, Unmanaged Projects
-will need to run the release job with the version of the final distribution no
-later than one week before code freeze.
+* Update their jenkins jobs: current release should point to the new created stable
+ branch and next release should point to master branch. If you do not know how to
+ do this please open a ticket to opendaylight helpdesk.
-Added to Final Distribution POM
-+++++++++++++++++++++++++++++++
+Release the project artifacts
++++++++++++++++++++++++++++++
+
+Self-Managed projects wanting to participate in the formal (major or service) release
+distribution must release and publish their artifacts to nexus in the week after the
+Managed release is published to nexus.
-In order to be included in the final distribution, Unmanaged Projects must
-submit a patch to include themselves in the final distribution pom.xml file no
-later than one week before code freeze. Projects should only be added to the final
-distribution pom.xml after they have published artifacts with the release job
-to avoid breaking the build.
+Self-Managed projects having an stable branch with latest upstream SNAPSHOT (see
+previous requirements) can use the release job in :doc:`project-release` to release
+their artifacts.
-Unmanaged Release Process
--------------------------
+After creating the release, Self-Managed projects should bump the stable branch
+version to X.Y.Z+1-SNAPSHOT, this way any new merge in the stable branch will not
+interfere with pre-release artifacts.
-Unmanaged Projects are free to follow their own processes. To have their
-artifacts included in the final distribution, they need only follow the
-Requirements for Unmanaged Projects above by the deadlines. Note that Unmanaged
-Projects will not have any leeway for missing deadlines. If projects are not
-in the final distribution by one week before code freeze their artifacts will not be
-included in the final release, but they may still publish artifacts and help
-their consumers install them out-of-band.
+.. note:: Self-Managed Projects will not have any leeway for missing deadlines. If
+ projects are not in the final distribution in the allocated time (normally
+ one week) after the Managed projects release, they will not be included
+ in the release distribution.
Checkpoints
+++++++++++
-There are no checkpoints for Unmanaged Projects.
+There are no checkpoints for Self-Managed Projects.
-Moving a Project from Managed to Unmanaged
-------------------------------------------
+Moving a Project from Managed to Self-Managed
+---------------------------------------------
Managed Projects that are not required for dependency reasons can submit a
-**Project_Plan** issue to be Unmanaged to the TSC project in Jira. See details
+**Project_Plan** issue to be Self-Managed to the TSC project in Jira. See details
in the `Initial Checkpoint`_ section above. Requests should be submitted before
the start of a release. Requests will be evaluated by the TSC.
The TSC may withdraw a project from the Managed Release at any time.
-Installing Features from Unmanaged Projects
--------------------------------------------
+Installing Features from Self-Managed Projects
+----------------------------------------------
-Unmanaged Projects will have their artifacts included in the final release if
-they are available on-time, but they will not be available to be installed
+Self-Managed Projects will have their artifacts included in the final release
+if they are available on-time, but they will not be available to be installed
until the user does a repo:add.
-To install an Unmanaged Project feature, find the feature description in the
+To install an Self-Managed Project feature, find the feature description in the
system directory. For example, NetVirt's main feature:
system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
* In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable
-Release Schedule
-================
-
-The start date for odd release is September 7 and the start date for even
-release is March 7.
-
-.. list-table::
- :widths: 20 20 20 40
- :header-rows: 1
- :stub-columns: 1
-
- * - **Milestone**
- - **Time**
- - **Fluorine**
- - **Description**
-
- * - Release Start
- - Start Date
- - 2018-03-07
- - Declare Intention: Submit **Project_Plan** Jira item in TSC project
-
- * - Initial Checkpoint
- - Start Date + 2 weeks
- - 2018-03-22
- - Initial Checkpoint. All Managed Projects must have completed
- **Project_Plan** Jira items in TSC project.
-
- * - Release Integrated Deadline
- - Initial Checkpoint + 2 weeks
- - 2018-04-07
- - Deadline for Release Integrated Projects (currently ODLPARENT and
- YANGTOOLS) to provide the desired version deliverables for downstream
- Snapshot Integrated Projects to consume.
-
- * - Version Bump
- - Release Integrated Deadline + 1 day
- - 2018-04-08
- - Prepare version bump patches and merge them in (RelEng team). Spend the
- next 2 weeks to get green build for all MSI Projects and a healthy
- distribution.
-
- * - Version Bump Checkpoint
- - Release Integrated Deadline + 2 weeks
- - 2018-04-21
- - Check status of MSI Projects to see if we have green builds and a
- healthy distribution. Revert the MRI deliverables if deemed necessary.
-
- * - CSIT Checkpoint
- - Version Bump Checkpoint + 2 weeks
- - 2018-05-07
- - All Managed Release CSIT should be in good shape - get all MSI Projects'
- CSIT results as they were before the version bump. This is the final
- opportunity to revert the MRI deliverables if deemed necessary.
-
- * - Middle Checkpoint
- - CSIT Checkpoint + 8 weeks
- - 2018-07-05
- - Checkpoint for status of Managed Projects - especially Snapshot
- Integrated Projects.
-
- * - Code Freeze
- - Middle Checkpoint + 4 weeks
- - 2018-08-07
- - Code freeze for all Managed Projects - cut and lock release branch. Only
- allow blocker bugfixes in release branch.
-
- * - Final Checkpoint
- - TSC meeting 2 weeks after Code Freeze
- - 2018-08-23
- - Final Checkpoint for all Managed Projects.
-
- * - Formal Release
- - 6 months after Start Date
- - 2018-09-07
- - Formal release
-
- * - Service Release 1
- - 1 month after Formal Release
- - 2018-10-07
- - Service Release 1 (SR1)
-
- * - Service Release 2
- - 2 months after SR1
- - 2018-12-07
- - Service Release 2 (SR2)
-
- * - Service Release 3
- - 2 months after SR2
- - 2019-02-07
- - Service Release 3 (SR3)
-
- * - Service Release 4
- - 3 months after SR3
- - 2019-05-07
- - Service Release 4 (SR4) - final service release
-
- * - Release End of Life
- - 4 months after SR4
- - 2019-09-07
- - End of Life - coincides with the Formal Release of the current release+2
- versions and the start of the current release+3 versions
-
Vocabulary Reference
====================
* Managed Release Process: The release process described in this document.
* Managed Project: A project taking part in the Managed Release Process.
-* Unmanaged Project: A project not taking part in the Managed Release Process.
+* Self-Managed Project: A project not taking part in the Managed Release
+ Process.
* Simultaneous Release: Event wherein all Snapshot Integrated Project versions
are rewriten to release versions and release artifacts are produced.
* Snapshot Integrated Project: Project that integrates with OpenDaylight
Simultaneous Release. These projects are consumed by Snapshot Integrated
Projects based on release version numbers, not snapshot versions.
-.. _Committer Removal Process: https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process
+.. _Committer Removal Process: https://wiki-archive.opendaylight.org/view/TSC:Procedures_and_Processes#Committer_Removal_Process
+.. _Weather Page: https://jira.opendaylight.org/browse/TSC-132?jql=Project%20%3D%20TSC%20AND%20Type%20%3D%20%22Weather%20Item%22%20
Code Review / docs.git / blobdiff