+.. _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.
+the following projects are Release Integrated:
+
+* aaa
+* controller
+* infrautils
+* mdsal
+* netconf
+* odlparent
+* yangtools
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.
* 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
------------------------------------------
Self-Managed Projects
=====================
-Requirements for Self-Managed 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
++++++++++++++++++
-Self-Managed Project requirements are designed to be as low-overhead as
-possible while still allowing for participation in the final release. If
-Self-Managed 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:
-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 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 Self-Managed Projects Running
-+++++++++++++++++++++++++++++++++++++++++++++++
+* Update .gitreview for stable branch: change defaultbranch=master to stable branch.
+ This way folks running "git review" will get the right branch.
-Self-Managed Projects that wish to take part in the final release must enable
-the validate-autorelease job. Self-Managed Projects can release artifacts at
-any time using the release job. To take part in the final release, Self-Managed
-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, Self-Managed 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.
-Self-Managed 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.
-Self-Managed Projects are free to follow their own processes. To have their
-artifacts included in the final distribution, they need only follow the
-Requirements for Self-Managed Projects above by the deadlines. Note that
-Self-Managed 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
+++++++++++
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