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 #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 #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.
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.
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
hyperSpecwill be carried out. I'm starting this issue as a place to gather our thoughts and discuss.Currently we have the following
hyperSpecbranches:hyperSpecincbeleites/hyperSpecmaster branch vers 0.99-20200521hyperSpecincbeleites/hyperSpecdevelop branch vers 0.100.0r-hyperspec/hyperSpecDONEThings to do or remember (in no particular order just yet):
developversions ofr-hyperspec/...must all work together.DESCRIPTIONfile). This works fine for the new packages which will use the CRAN version ofhyperSpec. These checks should continue to work when thedevelopbranch ofhyperSpecbecomes themasterbranch and is released to CRAN. But this needs further careful consideration.r-hyperspec/hyperSpecwill be VG but need to convey this to CRAN).ctb,autetc..onAttachfile which issues a message along the line "This package is intended for use for hyperSpec 1.0 or higher".Additional_repositoriesfield inDESCRIPTIONand make sure if we want it there or not.developbranch intomaster.NEWS.mdREADME.mdSee here for one aspect.Here is my release checklist (edited slightly for
r-hyperspec/...). The stuff above needs to be integrated.developbranchNEWS.mdentries & updateREADME.md. Are the badges correct?r-hyperspec/...)R-hubbuilds everything from source, so THIS IS SLOW.developversion & push to Github. Note: git tagdevelopversion to Github (triggers B & C for certain branches).developinto master & push master to Github (triggerspkgdowndocumentation update, and B & C)pkgdownsite if presentdevelopbranch