Submit an updated version of bfast to CRAN

[GreatEmerald]

To update the package on CRAN, there are a few options. The first way, the simplest one, would be:

• [ ] Push the current updates on CRAN for the 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 to strucchange.

If we want to use the new functionality, we also want to have an update to strucchange, on which bfast could depend. Here the roadmap would be one of the two:

• [ ] Split out the C++ part of bfast2/strucchange into its own package, e.g. strucchangeArmadillo
• [ ] Submit strucchangeArmadillo to CRAN
• [ ] Submit all the changes in bfast2/bfast to upstream strucchange
• [ ] Add checks in bfast for whether strucchangeArmadillo is loaded and then if so, use it, otherwise warn users that a slow codepath is being used
• [ ] Submit bfast to CRAN

This 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:

• [x] Rename bfast2/strucchange to strucchangeArmadillo and mention that it is a fork of strucchange at a certain revision
• [x] Submit strucchangeArmadillo to CRAN
• [x] Switch dependency in bfast from strucchange to strucchangeArmadillo
• [x] Submit bfast to CRAN

It's useful to discuss which way we should choose to proceed.

[GreatEmerald]

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.

[GreatEmerald]

Plan #3 complete!