Signed-off-by: Guillaume Lambert <guillaume.lambert@orange.com>
Change-Id: Icadc2a6aaaed2c8cc6312ec3d4ee331abfb0a0a3
**************************
This page explains how a project can release independently outside of the
**************************
This page explains how a project can release independently outside of the
-OpenDaylight simultanious release.
+OpenDaylight simultaneous release.
Preparing your project for release
==================================
Preparing your project for release
==================================
This job performs the following duties:
1. Removes -SNAPSHOT from all pom files
This job performs the following duties:
1. Removes -SNAPSHOT from all pom files
-2. Produces a taglist.log, project.patch, and project.bundle files
-3. Runs a `mvn clean deploy` to a local staging repo
-4. Pushes the staging repo to a Nexus staging repo
+2. Produces a ``taglist.log``, project.patch, and project.bundle files
+3. Runs a `mvn clean deploy` to a local staging repository
+4. Pushes the staging repository to a Nexus staging repository
https://nexus.opendaylight.org/content/repositories/<REPO_ID>
https://nexus.opendaylight.org/content/repositories/<REPO_ID>
- (REPO_ID is saved to staging-repo.txt on the log server)
-5. Archives taglist.log, project.patch, and project.bundle files to log server
+ (REPO_ID is saved to ``staging-repo.txt`` on the log server)
+5. Archives ``taglist.log``, project.patch, and project.bundle files to log
+ server
-The files taglist.log and project.bundle can be used later at release time to
-reproduce a byte exact commit of what was built by the Jenkins job. This can
-be used to tag the release at release time.
+The files `̀`taglist.log`` and `̀ project.bundle`̀` can be used later at release
+time to reproduce a byte exact commit of what was built by the Jenkins job.
+This can be used to tag the release at release time.
Releasing your project
======================
Releasing your project
======================
-Once testing against the staging repo has been completed and project has
-determined that the staged repo is ready for release. A release can the be
+Once testing against the staging repository has been completed and project has
+determined that the staged repository is ready for release. A release can the be
performed using the self-serve release process:
https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html
performed using the self-serve release process:
https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html
- Middle Checkpoint + 4 weeks
- Start Date +20 weeks
- Code freeze for all Managed Projects - cut and lock release branch. Only
- Middle Checkpoint + 4 weeks
- Start Date +20 weeks
- Code freeze for all Managed Projects - cut and lock release branch. Only
- allow blocker bugfixes in release branch.
+ allow blocker bug fixes in release branch.
* - Final Checkpoint
- 2021-08-19
- 2021-03-08
* - Final Checkpoint
- 2021-08-19
- 2021-03-08
.. important::
**DO NOT** enable Code-Review+2 and Verified+1 to the
.. important::
**DO NOT** enable Code-Review+2 and Verified+1 to the
- Release Engienering Team during code freeze.
+ Release Engineering Team during code freeze.
.. note::
Enable **Exclusive** checkbox for the submit button to override any
.. note::
Enable **Exclusive** checkbox for the submit button to override any
- existing persmissions. Code-Review and Verify permissions are only needed
+ existing permissions. Code-Review and Verify permissions are only needed
Release Preparations
====================
Release Preparations
====================
-After release candidate is built gpg sign artifacts using the
+After release candidate is built GPG sign artifacts using the
:doc:`lftools sign <lftools:commands/sign>` command.
.. code-block:: bash
:doc:`lftools sign <lftools:commands/sign>` command.
.. code-block:: bash
Projects such as OpFlex participate in the Simultaneous Release but are not
part of the autorelease build. Ping those projects and prep their staging
Projects such as OpFlex participate in the Simultaneous Release but are not
part of the autorelease build. Ping those projects and prep their staging
Bulleted actions can be performed in parallel while numbered actions should be
done in sequence.
Bulleted actions can be performed in parallel while numbered actions should be
done in sequence.
-- Release the Nexus Staging repos
+- Release the Nexus Staging repository
- #. Select both the artifacts and signature repos
+ #. Select both the artifacts and signature repository
(:ref:`created previously <simrel-preparations>`) and ``click Release``.
#. Enter ``Release OpenDaylight $RELEASE`` for the description and
(:ref:`created previously <simrel-preparations>`) and ``click Release``.
#. Enter ``Release OpenDaylight $RELEASE`` for the description and
.. note::
Enable **Exclusive** checkbox for the submit button to override any
.. note::
Enable **Exclusive** checkbox for the submit button to override any
- existing persmissions. Code-Review and Verify permissions are only needed
+ existing permissions. Code-Review and Verify permissions are only needed
during version bumping. **DO NOT** enable it during code freeze.
#. Merge all patches generated by the job
during version bumping. **DO NOT** enable it during code freeze.
#. Merge all patches generated by the job
(eg. |release|-SR1). Skip this step.
For major releases the notes come from the projects themselves in the docs
(eg. |release|-SR1). Skip this step.
For major releases the notes come from the projects themselves in the docs
- repo via the `docs/releaset-notes/projects` directory.
+ repository via the `docs/releaset-notes/projects` directory.
For service releases (SRs) we need to generate service release notes. This
can be performed by running the autorelease-generate-release-notes-$STREAM
For service releases (SRs) we need to generate service release notes. This
can be performed by running the autorelease-generate-release-notes-$STREAM
./scripts/release-notes-generator.sh ${RELEASE}
A ``release-notes.rst`` will be generated in the working directory. Submit
./scripts/release-notes-generator.sh ${RELEASE}
A ``release-notes.rst`` will be generated in the working directory. Submit
- this file as ``release-notes-sr1.rst`` (update the sr as necessary) to the
+ this file as ``release-notes-sr1.rst`` (update the ``sr`` as necessary) to the
+Autorelease
+autorelease
+abelur
+analytics
+config
+deliverables
+dev
+eg
+pre
+reachability
+releng
+rovarga
+TSC
+tsc
+uncheck
+virtualenv
+xml
architecture must help. Include information to describe if the project
is within ODL installation package or to be installed separately.
architecture must help. Include information to describe if the project
is within ODL installation package or to be installed separately.
-Pre Requisites for Installing <Feature>
+Pre-Requisites for Installing <Feature>
=======================================
* Hardware Requirements
=======================================
* Hardware Requirements
Preparing for Installation
==========================
Preparing for Installation
==========================
-Include any pre configuration, database, or other software downloads
+Include any pre-configuration, database, or other software downloads
required to install <feature>.
Installing <Feature>
required to install <feature>.
Installing <Feature>
RESTCONF usage
~~~~~~~~~~~~~~
RESTCONF usage
~~~~~~~~~~~~~~
-Opendaylight config subsystem NETCONF northbound is not made available just by installing
+OpenDaylight config subsystem NETCONF northbound is not made available just by installing
``odl-distribution-version``, but most other feature installations would enable it.
RESTCONF interfaces are enabled by installing ``odl-restconf`` feature,
but that do not allow access to config subsystem by itself.
``odl-distribution-version``, but most other feature installations would enable it.
RESTCONF interfaces are enabled by installing ``odl-restconf`` feature,
but that do not allow access to config subsystem by itself.
refer to each individual provider’s documentation. Since the Neutron
service only provides the northbound API for the OpenStack Neutron ML2
mechanism driver. Without those provider features, the Neutron service
refer to each individual provider’s documentation. Since the Neutron
service only provides the northbound API for the OpenStack Neutron ML2
mechanism driver. Without those provider features, the Neutron service
Neutron Service feature Architecture
------------------------------------
Neutron Service feature Architecture
------------------------------------
stabilizes.
``odl-neutron-service`` provides only a unified interface for OpenStack
stabilizes.
``odl-neutron-service`` provides only a unified interface for OpenStack
-Neutron. It doesn’t provide actual functionality for network
+Neutron. It does not provide actual functionality for network
virtualization. Refer to each OpenDaylight project documentation for
actual configuration with OpenStack Neutron.
virtualization. Refer to each OpenDaylight project documentation for
actual configuration with OpenStack Neutron.