Decide on package development workflow and release policies

[nikosbosse]

We should decide on a coherent policy for how we develop the package. Relevant questions are: where does the development version sit and how should we manage the docs at https://epiforecasts.io/scoringutils?

Status quo:

Our Readme says:

• stable version on CRAN
• stable development: install.packages("scoringutils", repos = "https://epiforecasts.r-universe.dev")
• unstable development version on main branch: remotes::install_github("epiforecasts/scoringutils", dependencies = TRUE).

In reality:

• version on main currently equal to the stable version on CRAN
• unstable development version on the develop branch
• the docs at https://epiforecasts.io/scoringutils get updated based on every PR to either main or develop (even before merging into develop)

This seems pretty bad and we should urgently fix that.

Possible solutions

Option A:

• stable version on CRAN
• unstable development version on main
• pkgdown docs get built on github releases, and every github release corresponds to a CRAN release, such that the docs always correspond to the CRAN version
• (somewhat unsure how the r-universe fits in)

Option B:

• stable version on CRAN and on main. Pretty much every change to main should correspond to a CRAN release
• pgkdown docs are built on pushes to main
• unstable development version on develop. Readme should point to that
• (somewhat unsure how the r-universe fits in)

Option C? I don't have a very good grasp of what best practices should look like. But it seems to me like we should make sure that the docs at https://epiforecats.io/scoringutils correspond to the version on CRAN, otherwise things can quickly get confusing for users.

[nikosbosse]

@sbfnk @seabbs what do you think?

EpiNow2 also updates docs on pushes to main and develop which I think implies that the docs are ahead of the CRAN version.

[seabbs]

It uses auto deployment so it's updating the dev version on develop and main (not that it has a develop version). If we made it have a non dev version it would make them release docs

[nikosbosse]

Note sure I can follow entirely. That means the semantic version number controls what gets released to the docs and that number is controlled by auto deployment?

[seabbs]

stick with the current workflow and prevent the docs being deployed on develop I think. Use auto deployment in the pgkdown yaml and dev package versions that the CRAN docs are at the root of the address and the develop docs (i.e from main) are at /dev/

[nikosbosse]

Summary of what we're planning to do:

• stable version is on CRAN
• development version will be on main and have a development version number, i.e. something like 1.2.2.9000
• this means that the documents on epiforecasts.io/scoringutils will track the latest stable release (which should also be on CRAN) and epiforecasts.io/scoringutils/dev will track the docs for the development version.

Question: what do we do when we have like 50 commits on main ahead of CRAN, but are not ready for a new release, and then want to patch something in the stable version?

[seabbs]

I think the solution there is to make a release branch and cherry pick the commits that we want from the development version into it and then release to CRAN from there.