Consider deprecating support for R versions older than 4 about actions HOT 8 OPEN

relevant read https://blog.r-hub.io/2022/09/12/r-dependency/#:~:text=this%20is%20the%20strategy%20used,up%20to%205%20years%20old.

from actions.

Not sure in every case to be honest. In the most recent case (that I added), it was because of code used in testing.

from actions.

Transferring this issue to https://github.com/RMI-PACTA/demo_actions/issues

from actions.

I feel like R v3.5 (April 2018) was a really significant release with the introduction of the ALTREP framework and the introduction of v3 serialization for native R objects (e.g. <3.5 cannot read the default versions of RDS/RDA files created by 3.5+)... so that feels like a good benchmark minimum.

from actions.

3.5.0 makes sense in that case. In any case, I think this relates to #33, where a good check here is to try running things on 3.5 and see how many things don't work.

from actions.

@jdhoffa Are we skipping the tests because of the code used in testing, or because of the code used in the app?

from actions.

One more thought here: When I was working in government, it was not uncommon for some of the software I used to be very outdated. If the P4B code supports the R 3.x releases, maybe we should keep it that way. 3.0.3 came out ~10 years ago (which is coincidentally how old the version of SQL Server I was using was before it got end-of-life'd on security updates, and we were forced to update).

Point being: in a security controlled environment, new features aren't compelling reasons to upgrade (I would not be surprised if some of those environments are still running R 3.0.0).

from actions.

All valid points. And Banks are likely in a similar setup to governments with restricted setups that may only support older versions, so perhaps 3.5 is a good baseline.

from actions.