If you're doing interactive exploration, though, there's little reason not to update. If you're in a production environment, and just want your code to run when called in two years, sure, lock down an environment in a VM. On the other hand, I have seen a lot of bugs that have been fixed by updates. Even when things are deprecated, they tend to stay that way for a good while before they ever get removed, so updating is more likely to generate warnings than errors.
Most of the ones I can think of ( by_row/ by_slice/ dmap moving to purrrlyr, dbplyr getting split out from dplyr) were really just relocations that didn't require significant changes to code (though the former was a sort of deprecation). Given a general mandate for at least some level of backwards compatibility among package maintainers, I've seen very few bugs introduced by updating. This post describes this idea in the context of software development: I like to spend my troubleshooting time on things that are likely to benefit the most people, going forward in time.įinally, I think there's also an element of "if it hurts, do it more often".
Much more so than figuring out how to get an old version of X to work smoothly with an old version of Y. Second, even when we run into trouble (which happens with new stuff!), discovering and fixing bugs in current packages seems like a very worthwhile activity. I also show and use features in packages/functions that have come about more recently. So I wouldn't say that everything needs to be bleeding edge, but some reasonable definition of current.įirst, we don't want to bump into bugs that have already been fixed. I see so many time capsules! As in, systems that appear to be frozen circa 2016 or thereabouts. My motivation for recommending that people update R, RStudio, and their packages at the start of every course I teach is.
0 kommentar(er)
