Release dev guide 1.0.0

[maelle]

Repo maintenance between releases

• Look at the issue tracker for the dev guide and for software review meta for changes still to be made in the dev guide. Assign dev guide issues to milestones corresponding to versions, either the next one or the one after that, e.g. version 0.3.0. Encourage PRs, have them reviewed.

1 month prior to release

• Remind editors to open issues/PRs for items they want to see in the next version.

• Run the devguide_prerelease() function from the devguider package.

• Ask editors for any feedback you need from them before release.

• For each contribution/change make sure the NEWS in Appendix.Rmd were updated.

• Plan a date for release in communication with rOpenSci's Community Manager who will give you a date for publishing a blog post / tech note.

2 weeks prior to release

• Draft a blog post / tech note about the release with enough advance for editors and then Community Manager to review it (2 weeks). Example, General blog post instructions, specific instructions for release posts.

• Make a PR from the dev branch to the master branch, ping editors on GitHub and Slack. Mention the blog post draft in a comment on this PR.

Release

• Check URLs using the devguide_urls() function from the {devguider} package

• Check spelling using the devguide_spelling() function from the {devguider} package. Update the WORDLIST as necessary.

• Squash and merge the PR from dev to master.

• GitHub release, check Zenodo release.

• Re-build (for Zenodo metadata update in the book) or wait for daily build

• Re-create the dev branch

• Finish your blog post / tech note PR. Underline the most important aspects to be highlighted in tweets as part of the PR discussion.