backcalc_opts() rename

[seabbs]

This is currently quite a misleading name and I think should be changed. One potential option is to call it dencolve_opts but could also call it something linking to its underlying model more closely? As this release is now looking like it will make quite a few breaking changes it would be nice to resolve this now.

It might also make sense to split the models into their own functions instead of the current approach with one perhaps being deconvolve and the other Rt? I’m not totally sure what the best names would be there. It would also make things tricky with higher level functions where they could be used interchangeably but not impossible (this is perhaps a larger change that should be saved for #352 if that goes ahead).

[sbfnk]

This is currently quite a misleading name and I think should be changed. One potential option is to call it dencolve_opts but could also call it something linking to its underlying model more closely? As this release is now looking like it will make quite a few breaking changes it would be nice to resolve this now.

It might also make sense to split the models into their own functions instead of the current approach with one perhaps being deconvolve and the other Rt? I’m not totally sure what the best names would be there. It would also make things tricky with higher level functions where they could be used interchangeably but not impossible (this is perhaps a larger change that should be saved for #352 if that goes ahead).

That happened #345 (see stan functions) and tentative R option interface but if going ahead that branch needs to be rebased to include the latest change and then the R option interface updated and finished).

[seabbs]

Aha one (or several) steps ahead. I'd forgotten how nice this was. I'm looking at rebasing it now and getting a handle on how much work is needed.

[seabbs]

Do you have thoughts about when we should try and add this in (i.e this release or next)?

Along with your suggestion for dist_spec there are a lot of breaking changes and looking over the process PR it feels like there is still a fair bit to do?

Part of me thinks we release what is on develop (which I think is breaking changes free as is) as is and then have a major release with all these breaking changes in a few weeks (basically bump up to a 2.0 release) in what can be the "paper" release.

[sbfnk]

Yes that sounds good to me - so 1.3.3 is what's currently in main (not on CRAN), 1.3.4 what's currently in develop (to go to CRAN), and 1.4 or 2.0 will be with an updated user interface for distributions and process but continuing with generation_interval_opts etc. so we're not intending to introduce them in one and then remove them in the next version?

[seabbs]

No, I think we would have to introduce and then remove in the updated version (or perhaps remove as that is still up in the air). The only thing that would be new though is generation_time_opts() but given that it isn't compulsory to use it doesn't seem like the end of the world. We could even update the documentation to not show its usage.

[seabbs]

main currently has a lot of fixes not in 1.3.3 (as released on GitHub) so is really a partial 1.3.4 (hence having an update version).