TITLE | P01: Create documentation for an ONAP main release |
SUBJECT | This procedure describes the required tasks for the ONAP doc project itself and supplying ONAP projects to create release-specific documentation for an ONAP main release. |
TABLE OF CONTENTS | |
AUTHOR(S) | |
TASKS | Note: Not every step within a single task is listed here. For example, a detailed description of a 'git commit' and the following 'git review' process is not explained. |
Update 'doc/docs/release-notes.rst' in the 'master' branchThis file contains a description of the latest changes in the 'doc' project. Update it accordingly for the new release. Example: 'release-notes.rst' in the 'master' release/branch | |
Update 'doc/docs/release/index.rst' in the 'master' branchThis file contains an (marketing) overview about the advantages and latest developments in the new release. It is also known as the 'composite release note'. The text is authored by LFN marketing and the ONAP TSC chair. Update the file accordingly - especially the release date. Example: 'index.rst' (composite release note) in the 'master' release/branchOPEN: Add contacts and describe the process how and when to request the 'marketing' text. Currently responsible for this activity: Eric Debeau | |
Update 'doc/docs/release/releaserepos.rst' in the 'master' branchThis file contains a table of contents (TOC) for project specific release notes. There are several sections to reflect the current maintenance state of every project. In case, a project/repository is deployed via OOM (standard ONAP installation), its release note is part of the TOC - regardless if this project/repository is currently maintained, unmaintaind or in another state. Update it accordingly for the new release. Example: 'releaserepos.rst' in the 'master' release/branchOPEN: Add reliable source for 'release partizipating projects/repositories', their 'maintenance-state' and - in addition - those ('unmaintained') projects which are deployed in addition by OOM team. | |
Create a new branch of the 'doc' project in gerrit
OPEN: Evaluate if we can/should update all files AFTER we have created the branch (and having only 'placeholder' files in the 'master' branch). This may avoid confusion in case people are looking to 'master' and seeing release specific content (e.g. related to 'honolulu'). | |
Clone the new doc branch to your development environmentgit clone --branch <newbranch> --recurse-submodules ssh://<username>@gerrit.onap.org:29418/doc | |
Update 'doc/docs/conf.py' in the new branch
Note: The different 'intersphinx_mapping' sections in the 'conf.py' reflect the different state of development in the projects and their repositories. We have to differentiate between:
Example #1: 'conf.py' for the 'master' release/branchExample #2: 'conf.py' for the 'honolulu' release/branch
OPEN: Add reliable source for the info if/if not a project has branched. | |
Update 'doc/.gitreview' in the new branchAdd/update the 'defaultbranch' (e.g. 'defaultbranch=honolulu') Example: '.gitreview' for the 'honolulu' release/branch
OPEN: Add a description why this is important | |
Template
OPEN: Template |