PSA: We will drop support for R < 4.0.0 in the upcoming CRAN release of `rio`, 1.2.0

[chainsawriot]

Provided that the entire development toolchain now requires R >= 4.0.0 (testthat's dependency evaluate now requires R >= 4.0.0), maybe it's time to drop 3.6 CI and announce R>= 4.0.0 from now on?

Another idea is to write our own custom GHA workflow for 3.6 and announce some features are not supported for R < 4, e.g. parquet #427 . I can foresee that more packages, especially the ones maintained by Posit, will drop R < 4 soon, namely readxl, readr, and haven. But backward compatibility is still a pillar for this package (although it only turns back the release time window for around 1 yr from Apr 2020 to Apr 2019).

@schochastics thoughts?

[schochastics]

hmm tricky for such an "old" package. Personally, I'd just drop the support but there might be some legacy systems that need to rely on 3.6? But I think it is ok to take that risk (maybe with a proper announcement beforehand). I assume it wouldn't be too hard to revert changes if there is a surprise use case that we need to support?

[chainsawriot]

@schochastics

I think the intersection between "R 3.6 users in July 2024" and "I still need to use the cutting edge version of rio" is extremely close to zero, if not already zero. For those who needs to use R < 4.0 and the old CRAN version of rio for reproducibility purposes, they should know their way out.

From my view, I would also take the risk. Probably much less drastic a change than the changes we made to 1.0.0. As you said, if someone in the above-mentioned intersection speaks up against the move, we can revert.

[chainsawriot]

Close this perhaps when 1.3.0 is released.