Release Plan (planning now, detailed sequence later)

[bryanhanson]

Based on discussions it seems clear (at least to me) that we are ready to start thinking in detail about how the release of the new hyperSpec will be carried out. I'm starting this issue as a place to gather our thoughts and discuss.

Currently we have the following hyperSpec branches:

• CRAN-released hyperSpec in cbeleites/hyperSpec master branch vers 0.99-20200521
  • This branch should be left alone until we are ready to release the new hyperSpec to CRAN.
• hyperSpec in cbeleites/hyperSpec develop branch vers 0.100.0
  • All development should be done against this branch (which is the case). YES/DONE
  • This branch must diverge from the master branch in order to be ready.
  • This branch will be have its folder structure flattened per Automating Updates to the GHA Workflows (Proposal for r-hyperspec/hyperSpec) #11 DONE
  • This branch will be moved to r-hyperspec/hyperSpec DONE
  • Deprecated functions on this branch should call the new code that replaces the old code. See Deprecation: General Strategy. We should call the replacement function, right? #17

Things to do or remember (in no particular order just yet):

• Prior to release, the develop versions of r-hyperspec/... must all work together.
• The GHA workflows build and check against the CRAN versions of packages they depend on (per their DESCRIPTION file). This works fine for the new packages which will use the CRAN version of hyperSpec. These checks should continue to work when the develop branch of hyperSpec becomes the master branch and is released to CRAN. But this needs further careful consideration.
• Obviously we need to deal with almost all issues in each package before a release.
• Special attention should be paid to the CRAN 1.0 milestone https://github.com/cbeleites/hyperSpec/milestone/3
• I think it would be a good idea to mark all issues in all repos with the CRAN 1.0 label if they need to be fixed before release. DONE
• Verify the maintainer for each repo (r-hyperspec/hyperSpec will be VG but need to convey this to CRAN).
• Verify that each person is correctly marked in authors@R as ctb, aut etc.
• Perhaps each package should have an .onAttach file which issues a message along the line "This package is intended for use for hyperSpec 1.0 or higher".
• We need to look at the Additional_repositories field in DESCRIPTION and make sure if we want it there or not.
• Merge completed develop branch into master.
• Adjust version.
• Update NEWS.md
• Update README.md See here for one aspect.
• Look at Submission to CRAN: 2 potential pitfalls #8 and integrate those concerns here.
• Consider Easing the experience of existing users with the coming release #24

Here is my release checklist (edited slightly for r-hyperspec/...). The stuff above needs to be integrated.

• Be sure all software is up-to-date (R, R pkgs, BioC pkgs, Homebrew) for final local testing
• Clean up any stale branches
• Be sure you are on the develop branch
• Review issues on Github
• Review local to-do list
• Review CRAN check logs if applicable
• Clean up the code, removing stale chunks etc
• Run styler on code
• Review the DESCRIPTION file (right authors, right maintainers, right version?)
• Review NEWS.md entries & update
• Update README.md. Are the badges correct?
• Build, Check, make all necessary changes
• Check examples
• Check manual
• Run any separate test suites (probably none in r-hyperspec/...)
• Review pdf vignettes(s) -- html are checked later
• Review any interactive functions (are there any?)
• Check package on win-builder
• Check package on R-hub.- [ ] Caution: R-hub builds everything from source, so THIS IS SLOW.
• Make sure vignette yaml specifies pdf documentation (needed for CRAN)
• Submit to CRAN, fix as needed, wait for approval
• Switch vignette yaml to specify html documentation
• Tag develop version & push to Github. Note: git tag ; git push origin devel --tags (that's - - tags, two dashes). Example : "CRAN_1.0"
• Push develop version to Github (triggers B & C for certain branches).
• Switch to master branch
• Merge develop into master & push master to Github (triggers pkgdown documentation update, and B & C)
• Check GHA-generated pkgdown site if present
• Switch back to develop branch
• Tweet about update
• Blog about update