Closed GreatEmerald closed 3 years ago
Discussing with @mirt001, we think that the last option is worth trying, i.e. try to first submit our fork of strucchange and then try to submit bfast with a dependency on it.
We decided to go for the name strucchangeRcpp
to make it shorter and to not conflict with the package on r-forge.
Plan #3 complete!
To update the package on CRAN, there are a few options. The first way, the simplest one, would be:
bfast
package only.This is doable because none of the updates specifically depend on an update to
strucchange
. The downside is that for much of the new functionality (e.g. increase in speed and most of the new features, plus bug fixes), the users are very interested in the updates done tostrucchange
.If we want to use the new functionality, we also want to have an update to
strucchange
, on whichbfast
could depend. Here the roadmap would be one of the two:bfast2/strucchange
into its own package, e.g.strucchangeArmadillo
strucchangeArmadillo
to CRANbfast2/bfast
to upstreamstrucchange
bfast
for whetherstrucchangeArmadillo
is loaded and then if so, use it, otherwise warn users that a slow codepath is being usedbfast
to CRANThis plan has a downside in that splitting the whole codebase of
bfast2/strucchange
would take a lot of time that we currently most likely do not have (volunteers welcome). Alternatively:bfast2/strucchange
tostrucchangeArmadillo
and mention that it is a fork ofstrucchange
at a certain revisionstrucchangeArmadillo
to CRANbfast
fromstrucchange
tostrucchangeArmadillo
bfast
to CRANIt's useful to discuss which way we should choose to proceed.