Repository navigation
release 1.14.10 #5709
Description
Activity
1.14.8...hotfix1.14.10
this will be useful before release to ensure all items have been coveredReacted by Tyson BarrettThanks, will get to this over the weekend. Appreciate you setting it up. So the changes for is.atomic() and the suppression of warnings is the only changes I'm seeing, which appear to be what is needed based on the CRAN tests.
A few questions since we are just starting this new phase of having me release to CRAN:
- Assume we want to do minor updates to
NEWS.md? - Should I make updates to
DESCRIPTIONto add myself as the maintainer to ensure all contact about the submission comes to me? - Any additional checks that you recommend (e.g. reverse dependencies) be run in addition to the CI processes already in place? This is such a small release that it may not be necessary, but thought I'd get your thoughts on it.
- Assume we want to do minor updates to
There few more things, all related are on the 1.14.9 milestone.
- yes, mention in news file will be needed
- yes
- ideally would be to go through release checklist, even for setting up and understanding the process. It will now be much easier than later on with 1.15.0 because very few things changed so should go very smoothly.
Reacted by Tyson BarrettSounds good. I'll do those and review the release checklist in depth to start to get comfortable with it.
I agree, it's very convenient we get to do a "practice" round with this much smaller release in advance of the larger 1.15 release.
I don't think revdep checks are necessary for patch releases like this.
Reacted by Tyson Barrett and Jan GoreckiI pushed NEWS file. It will still need minor amendment when closing #5695
Reacted by Tyson BarrettUpdated the dsc file in hotfix1.14.10
@jangorecki looks like we are waiting on a fix for shift before we submit the patch?
Yes, only shift fix is left and we are good for CRAN submission. At the very last moment it is worth to look at CRAN check results, in case another breaking change in R-devel will suddenly popup, so we can still put the fix at the last moment.
I haven't seen any activity on
shift()yet. I'm still waiting on that before submission.Shift was addressed by Michael
Thanks, will set up the CRAN submission this weekend.
16 remaining items
I am also puzzled by this IDate check NOTE.
Tried (on r 4.3.2)
_R_CHECK_S3_METHODS_NOT_REGISTERED_=truebut no luck.
Found wch/r-source@9e9c839If anyone will find a switch for that please let me know so I will add in CI.
Maybe this change is too big for the patch/hotfix, but instead of using
setDTthreads(1)to fix The "Re-building vignettes had CPU time ..." check, we could get the 2.5 ratio from the CRAN environment variable_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD_so and then round down as a default for number of threads, as I proposed here #5807@tdhock would that still guarantee we'd avoid that note? I assume it would but thought I'd ask. For the patch release I'll do 1 thread but I think we should consider this for the 1.15
CRAN checks on that are unreliable. There are reports from users that set limit to 2 but still had those notes (for examples, not vignettes). As long as CRAN does not provide reliable way to respect their policies, and as long as these are only vignettes/examples and not users code, then I feel it is better to set it to 1. Just be sure to re-set it at the end. To not change the state of environment that renders vignette.
Reacted by Tyson BarrettIs the best way to reset it by just running
setDTthreads()?.old.th = setDTthreads(1)
...
setDTthreads(.old.th)Reacted by Tyson BarrettPlease include those fixes in hotfix branch here, so branch reflects the version submitted to CRAN. Except for the version bump explained in the procedure.
it looks accurate, maybe it's a new check:
Yes, it's very new; I've seen it in a package of mine which has been unchanged for years.
Congrats to all, and especially the new maintainer !!, on getting a new version onto CRAN! On to the 1.15.* series then?
Reacted by Michael Chirico, Jan Gorecki, Benjamin Schwendinger, Toby Dylan Hocking and minemRindeed! trust dirk to be one of the first to spot the release :)
Reacted by Dirk Eddelbuettel- unpinned this issue
on Dec 8, 2023 @TysonStanley still please do tag 1.14.10 and push to git, as explained in release procedure, avoiding even version number in the package code. Only in git tag name we want to have even number.
It used to be happen couple times that after CRAN submission new errors has been detected in CRAN checks, that haven't been detected during submission. Then another patch release is needed (slide 9 from here shows that a bit https://jangorecki.gitlab.io/r-talks/2018-07-03_Wroclaw_What_s-new-in-data.table/What-s-new-in-data.table.pdf).
Then we just fork from 1.14.10 tag, add fixed and push as 1.14.12.When all jobs here https://cran.r-project.org/web/checks/check_results_data.table.html will be OK / NOTE on 1.14.10 then it means we are good. Windows jobs may have false positive failure after examples. It is marked as FAIL rather than ERROR.
Will do. Probably in the next few hours will be able to get to this.
Reacted by Jan Gorecki, Dirk Eddelbuettel and Toby Dylan HockingTagged the 1.14.10 release to CRAN with edits that passed CRAN checks (as far as have been run thus far)
https://github.com/Rdatatable/data.table/releases/tag/1.14.10
We are getting errors on CRAN due to changes in R-devel, therefore we should provide patched version for the current moment, rather then trying to push current master. Release of current master can as well follow the patch release, but releasing master should not be blocking patch release. There is still at least 1 pending issue to resolve in master before it will be ready for CRAN.
Ideally it will be the last release before moving to new governance structure (ultimately that depends on breaking changes in R-devel or breaking changes in CRAN policies).
Issues on a 1.14.9 (1.14.10) milestone should be merged to hotfix1.14.10 branch, and later on to master as well.