diff --git a/doc/contributor-guide/source/release/taskdetail.rst b/doc/contributor-guide/source/release/taskdetail.rst index a8d0924853..ea5792d27a 100644 --- a/doc/contributor-guide/source/release/taskdetail.rst +++ b/doc/contributor-guide/source/release/taskdetail.rst @@ -62,91 +62,56 @@ notes is `openstack-manuals/releasenotes/source/RELEASENAME` and they are published to `https://docs.openstack.org/releasenotes/openstack-manuals/RELEASENAME.html`. -Update www pages -~~~~~~~~~~~~~~~~ +Update www pages for end of release +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Make the following changes in the **openstack-manuals** repository: -#. Create the docs.openstack.org index page for the new release, using the - existing page as a template: - - - ``/www/RELEASE/index.html`` - -#. Copy the latest project data file to one named for the release: +#. Copy the "latest" project data file to one *named for the release + being completed*: .. code-block:: console $ cp www/project-data/latest.yaml www/project-data/RELEASE.yaml -#. Create the project-install-guide index page for the new release, using the - existing page as a template: +#. Create the docs.openstack.org pages for the *new* release, by + copying the existing templates to the new directory: - - ``/www/project-install-guide/RELEASE/index.html`` + .. code-block:: console -#. Modify the new file to set the ``SERIES`` variable for the template - correctly: + $ cp -a www/RELEASE www/NEXT_SERIES - .. code-block:: jinja +#. Update the ``RELEASED_SERIES``, ``SERIES_IN_DEVELOPMENT``, and + ``FUTURE_SERIES`` values in the template generator + (``tools/www-generator.py``). - {% set SERIES = "RELEASE" %} + This will cause docs.openstack.org to redirect to the + series-specific landing page for the current release, and the + templates for the release being completed will use the data from + the file created in the previous step. -#. Create the ``project-deploy-guide`` index for the new release, using the - existing page as a template: +#. Test the build locally with ``tox -e checkbuild``. - - ``/www/project-deploy-guide/RELEASE/index.html`` + If any project links are missing and cause the template generator + to fail, set the flags to disable linking to those docs. For + example, if "foo" does not have a configuration reference guide, + set ``has_config_ref: false`` for the "foo" project. -#. Add the new pages to the list in ``/www/www-index.html``. +.. warning:: - This patch should have a core -2 review on it until it is ready to be - published. This should happen about a week before release day, sending the - page live, but should remain unlinked until the last moment. This is to - allow the release team to link to the new page. + When the patch to make these changes merges, docs.openstack.org + will immediately update to redirect to the release. The previous + release pages will still be present at their old locations. -#. Update the drop-down menu. Merge this patch on release day: +.. note:: - - ``/www/templates/dropdown_releases_and_languages.tmpl`` - -#. Update the site redirects. Merge this patch on release day: - - - ``/www/.htaccess`` - -#. Update the *Get started* links. Do not merge this patch until after the - links are active: - - - ``/doc/common/get-started-with-openstack.rst`` - -Update links in all books -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Every book maintained by OpenStack Manuals must be checked for links -referencing the old release. Do one patch per book, and record the review -number in the release etherpad so that release managers can review easily. -For versioned books, these patches should have a core -2 review on them until -they are ready to be published at release time. For continuously released -books, these patches can be merged immediately. - -In some versioned guides, the master branch links to draft books in some -locations. Most notably, the basic Installation Tutorial links to the -additional services Installation Guides in -``doc/install-guide/source/additional-services.rst``. Update these links to -the correct version before publishing the book. - -Update main docs page -~~~~~~~~~~~~~~~~~~~~~ - -On release day, change the front page so the new release is the default by -synchronising `openstack-manuals/www/RELEASENAME/index.html`, which you -created earlier, with `openstack/openstack-manuals/www/index.html`. These -two files should have the same content. - -Merge all the release day patches prepared earlier. - -Changes to the docs site can take an hour or more to populate, depending on -the status of the gate and the number of changes being pushed at release time, -so be prepared to have the release day patches ready well ahead of the -official release time. You can check the current gate status at `Zuul status -`_ to get an idea of the current merge -times. + Changes to the docs site can take an hour or more to populate, + depending on the status of the gate and the number of changes being + pushed at release time, so be prepared to have the release day + patches ready well ahead of the official release time. You can + check the current gate status at `Zuul status + `_ to get an idea of the current + merge times. Generate the site map ~~~~~~~~~~~~~~~~~~~~~ @@ -156,46 +121,6 @@ docs.openstack.org using the ``sitemap`` script in the **openstack-doc-tools** repository. Copy the `sitemap.xml` file into the `www/static` directory in the **openstack-manuals** repository and commit the change. -Cut the branch -~~~~~~~~~~~~~~ - -Cut the branch for versioned guides. This usually happens about a month -after release day, but the timing is informed mainly by the volume of -changes going in to the guides. Cutting the branch is done by the -OpenStack Infrastructure team. - -Once the branch ``stable/RELEASENAME`` is created, a few things need -to be set up before any other changes merge: - -* Update the ``stable/RELEASENAME`` branch (`example stable branch change - `__): - - * Disable all non-translated and non-versioned guides for - translation. - * Only build backported guides (install-guide, config-reference, - networking-guide). - * Publish backported guides and their translations to - ``/RELEASENAME/``. - * Do not publish web pages. - * Update ``.gitreview`` for the branch. - -* Update the ``master`` branch (`example master branch change - `__): - - * Do not copy content anymore to ``/RELEASENAME``. - * Update the sphinxmark configuration files for versioned guides - with the latest release name. - - -Also, for translations the following needs to be done: - -* The translation server needs be set up for this. A version - ``stable-RELEASENAME`` needs to be set up as copy from ``master``. -* The OpenStack CI set up needs to be adjusted for the branch. Change - in ``openstack-infra/project-config`` the gerritbot notifications and - the import of translations (`example infra change - `__). - End-of-life ~~~~~~~~~~~ diff --git a/doc/contributor-guide/source/release/taskoverview.rst b/doc/contributor-guide/source/release/taskoverview.rst index c74595e284..74d1342809 100644 --- a/doc/contributor-guide/source/release/taskoverview.rst +++ b/doc/contributor-guide/source/release/taskoverview.rst @@ -21,21 +21,13 @@ Release day is usually 1300UTC on the `initial release date` listed on the Ping Speciality Team leads to review and update release notes for openstack-manuals. -*One to two weeks* - Publish project-specific docs to new branch, publish index pages to docs - (but leave unlinked). +*At RC1* + When projects create their branches and land the first patch, + they will automatically have branch-specific documentation. After + the branches are created, create the project data file in the + ``openstack-manuals`` repository for the new series. -*One week* - Check and update all books to have correct version information, and update - any links in each book to refer to the new release. Run scripts to pull the - latest changes for the Configuration Reference and CLI Reference Guides. - -*On release day* - Add new release name to the dropdown menu on the docs page, regenerate the - sitemap.xml, and change the front page so the new release is the default. - -*After release day* - Cut the branch for versioned guides. This usually happens about a month - after release day, but the timing is informed mainly by the volume of - changes going in to the guides. Update the sphinxmark configuration files - for versioned guides with the latest release name. +*Before or on release day* + Update the series settings in the template generator and add the + landing page for the next series by copying the templates from the + current release to the new release directory.