CRAN release

[seabbs]

its been 10 months since the last release since when multiple changes have occurred to the main branch. We need to urgently do a CRAN release once the recently identified bugs in #427 and the metrics table have been fixed. This will enable us to warn users now that a dev version is coming and to ask for any feedback on it. We could consider putting in an .onLoad rlang message about this (i.e that will show every 8 hours) given the scale of the change we are proposing. I think we should also give a date for releasing the updated develop version to CRAN so that users can be prepared (and then actually stick to this).

[seabbs]

@nikosbosse I hadn't realised that we had had no small releases in nearly a year. I think this is highest priority.

[seabbs]

I see 8 releases since 1.1.0 with releases up to 1.2.0 getting a GitHub release and 1.2.1 being used as the "release" pkgdown documentation. This means that all documentation is mismatched with CRAN with no way for users to find the correct documentation or in most cases even to tell.

[seabbs]

@sbfnk for visibility.

[nikosbosse]

To make sorting through the PRs a bit easier, these are the PRs that I think we should merge before the update:

• Issue #427: Fix error in set_forecast_unit() that occurs when input is not a data.table #487
• Issue 428 fix metrics table #489
• Issue #486: Add startup message for a new CRAN release #490
• optional: Create a PR template #491

Other than that I think everything is good to go for a release.

[nikosbosse]

Another PR needed to fix a few check issues on CRAN: #505

[seabbs]

Leaving this open until we:

• On CRAN
• Have a GitHub release
• Have a non-dev version of the docs that match the CRAN release

[nikosbosse]

Which docs are you referring to? I.e. are there any docs you think need updating immediately before the CRAN release?

[seabbs]

pkgdown

[nikosbosse]

Need to fix additional issues on CRAN:

* checking examples ... [26s/17s] NOTE
Examples with CPU (user + system) or elapsed time > 5s
              user system elapsed
add_coverage 6.914  0.313   0.638
Examples with CPU time > 2.5 times elapsed time
              user system elapsed  ratio
add_coverage 6.914  0.313   0.638 11.328

  Running ‘testthat.R’ [211s/18s]
Running R code in ‘testthat.R’ had CPU time 11.8 times elapsed time

* checking re-building of vignette outputs ... [168s/18s] NOTE
Re-building vignettes had CPU time 9.1 times elapsed time

* DONE
Status: 3 NOTEs

I think this is related to data.table using more cores than it is allowed to use. I remember having an issue like that before. I'm really unsure why this is happening, i.e. as far as I'm aware data.table should automatically detect when it's running on CRAN and only use a single core?

That issue appeared only on their Debain machine, on Windows it was fine:

Windows: https://win-builder.r-project.org/incoming_pretest/scoringutils_1.2.2_20231129_000243/Windows/00check.log
Status: OK
Debian: https://win-builder.r-project.org/incoming_pretest/scoringutils_1.2.2_20231129_000243/Debian/00check.log
Status: 3 NOTEs

I can manually set the number of threads to one I guess. But phew....

Interestingly that issue is only related to CRAN's Debian machine - checks pass on Windows. And since the current CRAN version of the package does fine, I assume they are only running regular checks on Windows? Otherwise the current version should fail as well.

I also reported the issue to the data.table maintainers (see Rdatatable/data.table#3300) and asked for advice.

[nikosbosse]

🎉

[nikosbosse]

Github Release is done as well.
@seabbs As far as I can tell docs are up to date now: https://epiforecasts.io/scoringutils
Do we night to update the R universe in some way?

We might want to the docs (or our setup?) a bit: Currently the docs say that the development version is on main, where really the development version is currently on the develop branch.

[seabbs]

We might want to the docs (or our setup?) a bit: Currently the docs say that the development version is on main, where really the development version is currently on the develop branch.

So the development version should be on main shortly right once we have a working prototype. That was the reason for going to CRAN with the current release. The thing to make sure of though is that we still have a dev version so that the currently published docs continue to refer to the actual released version.

[seabbs]

R universe will update itself

[seabbs]

but we likely don't want the dev version showing up in the docs at all for now as we may have to do additional patch releases to fix bugs for the code on main whilst the refactor is finalised.