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
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:hyperSpec
incbeleites/hyperSpec
master branch vers 0.99-20200521hyperSpec
incbeleites/hyperSpec
develop branch vers 0.100.0r-hyperspec/hyperSpec
DONEThings to do or remember (in no particular order just yet):
develop
versions ofr-hyperspec/...
must all work together.DESCRIPTION
file). This works fine for the new packages which will use the CRAN version ofhyperSpec
. These checks should continue to work when thedevelop
branch ofhyperSpec
becomes themaster
branch and is released to CRAN. But this needs further careful consideration.r-hyperspec/hyperSpec
will be VG but need to convey this to CRAN).ctb
,aut
etc..onAttach
file which issues a message along the line "This package is intended for use for hyperSpec 1.0 or higher".Additional_repositories
field inDESCRIPTION
and make sure if we want it there or not.develop
branch intomaster
.NEWS.md
README.md
See here for one aspect.Here is my release checklist (edited slightly for
r-hyperspec/...
). The stuff above needs to be integrated.develop
branchNEWS.md
entries & updateREADME.md
. Are the badges correct?r-hyperspec/...
)R-hub
builds everything from source, so THIS IS SLOW.develop
version & push to Github. Note: git tagdevelop
version to Github (triggers B & C for certain branches).develop
into master & push master to Github (triggerspkgdown
documentation update, and B & C)pkgdown
site if presentdevelop
branch