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.

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

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

Merged
merged 1 commit into from Jun 8, 2020

Conversation

zenmonkeykstop
Copy link
Contributor

Status

Ready for review

Description of Changes

Resolves #5081.

Updates release management docs with instructions on updating public documentation.

Testing

  • Docs-only PR, review for clarity and correctness.

Deployment

Any special considerations for deployment? Consider both:

  1. Upgrading existing production instances.
  2. New installs.

Checklist

If you made changes to documentation:

  • Doc linting (make docs-lint) passed locally

#. 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

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).

Copy link
Contributor

@kushaldas kushaldas left a comment

Choose a reason for hiding this comment

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

This is good, and simple step compared to the previous steps.

@kushaldas kushaldas merged commit 309f17e into develop Jun 8, 2020
SecureDrop Team Board automation moved this from Ready for Review to Done Jun 8, 2020
@zenmonkeykstop zenmonkeykstop mentioned this pull request Jun 9, 2020
2 tasks
@zenmonkeykstop zenmonkeykstop deleted the docs-update-rm-5081 branch July 21, 2021 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Show warning header on previous versions of documentation
3 participants