Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

updated release management guide with new instructions for docs build #5241

Merged
merged 1 commit into from
Jun 8, 2020
Merged

updated release management guide with new instructions for docs build #5241

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
24 changes: 4 additions & 20 deletions docs/development/release_management.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,26 +188,10 @@ Release Process
#. Ask Infrastructure to perform the DNS cutover to switch
``apt-qa.freedom.press`` to ``apt.freedom.press``. Once complete,
the release is live.
#. Make sure that the default branch of documentation is being built
off the tip of the release branch. Building from the branch instead
of a given tag enables us to more easily add documentation changes
after release. You should:

a. Log into readthedocs.
#. Navigate to **Projects** → **securedrop** → **Versions** →
**Inactive Versions** → **release/branch** → **Edit**.
#. Mark the branch as Active by checking the box and save your
changes. This will kick off a new docs build.
#. Once the documentation has built, it will appear in the version
selector at the bottom of the column of the.
#. Now set this new release as default by navigating to **Admin** →
**Advanced Settings** → **Global Settings** → **Default
Version**.
#. Select ``release/branch`` from the dropdown menu and save the
changes.
#. Verify that docs.securedrop.org redirects users to the
documentation built from the release branch.

#. Issue a PR to merge the release branch changes into ``master``. Once the PR is
merged, verify that the `public documentation <https://docs.securedrop.org/>`_
refers to the new release version. If not, log in to ReadTheDocs and start a
build of the ``master`` version.
Copy link
Member

@eloquence eloquence May 8, 2020 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous version said:

Building from the branch instead of a given tag enables us to more easily add documentation changes after release.

With this new process, I think we should make the expectations for post-release/post-tag docs updates even more explicit, to avoid confusion about what's permissible, and to avoid missing required steps.

What's the expected process going forward?

  1. Will we still permit post-tag backports of docs changes into the release branch, without creating a new tag?
  2. Will such docs changes then need to be individually ported into master, or is the expectation to do a single merge to master once towards the very end of the process?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the discussion at our retro, we also want to clarify what merge strategy we want to use here (ideally one that is low-effort, since master is only used for docs builds).

#. Create a `release
<https://github.com/freedomofpress/securedrop/releases>`_ on GitHub
with a brief summary of the changes in this release.
Expand Down