[ ] 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.
[ ] 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 @stefaniebutland who will give you a date for publishing a blog post / tech note.
Release book version
Repo maintenance between releases
1 month prior to release
[ ] Remind editors to open issues/PRs for items they want to see in the next version.
[ ] 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
@stefaniebutlandwho 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 Stef 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 corresponding script.
[ ] Spell check. 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.