Documentation edits: cosmetic
overview/architecture_overview.rst
----------------------------------
* Fixed dup "have been have been"
overview/lab_setup.rst
----------------------
* Correct VOLTHA cases and s/the/this/.
release_notes/release_process.rst
---------------------------------
* Updated jira notes to be more descriptive wrt edits needed.
Change-Id: I780a0835787f5e7d658c9b63451c78809114f9c9
diff --git a/VERSION b/VERSION
index b52282a..1a285c3 100755
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-2.10.4
+2.10.5
diff --git a/overview/architecture_overview.rst b/overview/architecture_overview.rst
index acb49e0..49e2729 100644
--- a/overview/architecture_overview.rst
+++ b/overview/architecture_overview.rst
@@ -76,7 +76,7 @@
of the system. An opensource implementation exists in the form of the `open-olt-adapter <https://github.com/opencord/voltha-openolt-adapter>`_) which uses
gRPC and the `openolt.proto <https://github.com/opencord/voltha-protos/blob/master/protos/voltha_protos/openolt.proto>`_
API as its means of communication to the ``open-olt-agent``. Closed source adapter
- that use different SB protocols to the device, such as NETCONF, have been have been proven to work with VOLTHA
+ that use different SB protocols to the device, such as NETCONF, have been proven to work with VOLTHA
with no changes required to the system.
- ``ONU Adapter``. The ONU adapter is responsible for all the interactions and commands towards the ONU via OMCI,
such as discovery, MIB upload, ME configuration, T-CONT and GEM port configuration and so on.
diff --git a/overview/lab_setup.rst b/overview/lab_setup.rst
index fd24d1a..47e8921 100644
--- a/overview/lab_setup.rst
+++ b/overview/lab_setup.rst
@@ -303,10 +303,10 @@
Configuration for in-band OLT control
-------------------------------------
-If OLT is being used in in-band connectivity mode, the
+If OLT is being used in in-band connectivity mode, this
`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
details the configuration aspects in ONOS and the aggregation switch to
-trunk/switch in-band packets from the OLT to BNG or Voltha.
+trunk/switch in-band packets from the OLT to BNG or VOLTHA.
In-band OLT software upgrade
-------------------------------------
diff --git a/release_notes/release_process.rst b/release_notes/release_process.rst
index 90ccc97..63be3af 100644
--- a/release_notes/release_process.rst
+++ b/release_notes/release_process.rst
@@ -12,12 +12,13 @@
``voltha-2.3``, etc. The rest of this section will use the ``voltha-2.3``
release as an example:
-A branch named ``voltha-2.3`` is created on the voltha-helm-charts repo. Release
-candidates will be created of each chart for the ``2.3`` release. The action that
-indicates the creation of the ``2.3`` release is to changing the `voltha
+A branch named ``voltha-2.3`` is created on the voltha-helm-charts repo.
+Release candidates will be created of each chart for the ``2.3`` release.
+The action that indicates the creation of the ``2.3`` release is to changing
+the `voltha
<https://gerrit.opencord.org/gitweb?p=voltha-helm-charts.git;a=tree;f=voltha>`_
-helm chart, and adapter charts with version: ``2.3.0`` specified in ``Chart.yaml``
-within the `voltha-helm-charts
+helm chart, and adapter charts with version: ``2.3.0`` specified in
+``Chart.yaml`` within the `voltha-helm-charts
<https://gerrit.opencord.org/gitweb?p=voltha-helm-charts.git;a=summary>`_ repo.
Accompanying tests for 2.3 are created by creating a branch created named
@@ -25,7 +26,7 @@
<https://gerrit.opencord.org/gitweb?p=voltha-system-tests.git;a=summary>`_
repo. At release we create a tag ``2.3.0`` on that branch.
-These two repos are the only ones that receive a ``2.3.0`` tag. Other repos that
+These two repos are the only ones receiving a ``2.3.0`` tag. Other repos that
contain individual components have their own versioning/release cadence, driven
by SemVer.
@@ -87,7 +88,8 @@
Process to create a change on a stable branch
-- Add a Jira item, with the ``Affects Version: ``VOLTHA vX.X`` set
+- Create a jira ticket for the problem and document the ``Affects Version/s:``
+ - field with affected version(s) ``VOLTHA vX.X``.
- Discuss and get consensus on the issue via the Voltha mailing list, in the
all-Voltha meeting, or on Slack about whether this fix should be brought to a
stable branch
@@ -112,11 +114,10 @@
API Deprecation policy
----------------------
-
-VOLTHA has in place a 2 release deprecation policy. Starting from ``voltha-2.9`` the APIs that are marked as deprecated
-are automatically removed after 2 releases.
-As an example an API marked as deprecated in ``voltha-2.9`` will be removed after the ``voltha-2.10`` release
-and will not be present anymore in ``voltha-2.11``.
+VOLTHA supports 2 release deprecation policy. Starting from ``voltha-2.9``
+the APIs that are marked as deprecated are automatically removed.
+For example an API marked as deprecated in ``voltha-2.9`` will be removed after
+the ``voltha-2.10`` release and will not be present anymore in ``voltha-2.11``.
The removal process is intended to happen automatically, meaning no further notice of removal needs to be sent out.
The deprecated objects and APIs are marked in the `voltha-protos <https://github.com/opencord/voltha-protos>`_ using the