+.. _managed-release:
+
***************
Managed Release
***************
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.
+ odlparent, yangtools and mdsal are the only Release Integrated Projects, but
+ others may join them in the future.
Requirements for Managed Projects
---------------------------------
.. code-block:: none
- This is a request for a project to move from Self-Managed 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.
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. This section includes the requirements
- and release process for these projects.
+ 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
- and installation instructions. There are no specific requirements for
+ 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 formal release
-----------------------------------------------------------------
+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 they must have their upstream
+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 the formal release, or by the previous release if they want to be in a
+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 Final Distribution
-+++++++++++++++++++++++++
+Add to Common Distribution
+++++++++++++++++++++++++++
-In order to be included in the formal (major or service) release final distribution,
-Self-Managed Projects must be in the final distribution pom.xml file and the
+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
.. 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. See
+ high chances for missing the formal release distribution. See
`Release the project artifacts`_.
+Cut Stable Branch
++++++++++++++++++
+
+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.
+
+After creating the stable branch Self-Managed projects should:
+
+* 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.
+
+* Update .gitreview for stable branch: change defaultbranch=master to stable branch.
+ This way folks running "git review" will get the right branch.
+
+* 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.
+
Release the project artifacts
+++++++++++++++++++++++++++++
-Self-Managed Projects wanting to participate in a formal (major or service) release,
-must perform the following tasks in the week after the Managed release is published
-to nexus:
+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.
+
+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.
-#. Bump their upstream version to latest Managed release.
-#. Release the project and publish the artifacts to nexus. All projects have
- a job for this.
-#. Add their release artifact to the full distribution.
+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.
.. 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 formal release.
+ in the release distribution.
Checkpoints
+++++++++++
Code Review / docs.git / commitdiff