我刚刚开始使用R，并且不确定多久更新已安装的软件包（此时，我主要使用的是ggplot2和拨浪鼓）。一方面，这是拥有最新版本的典型极客冲动:-)另一方面，更新可能会破坏功能，作为R初学者，我不想浪费时间研究包不兼容性并重新安装库，这几乎可以肯定我不会注意到改进的包装有任何区别。
对于其他应用程序，我从根据升级频率，升级版本和安装等等之间的经验等方面发展而来。但是对于R来说，我处在黑暗中。
要明确：我不是在讨论R本身，而是在讨论它的库。
感谢。
答案 0 :(得分：16)
这是我的理念：天真的用户永远不会更新。老练的用户总是会更新。高级用户经常更新，但要小心。
无意识更新并不总是有益的。错误在R库的更新版本（或R本身！）中发挥作用，您可以通过更新来破坏现有代码，而无需读取更改日志或提交历史记录。例如，R 2.11在OS X上破坏了lme4 ...在版本之间仔细更新和运行包的演示是值得的。更新到新的库或R版本并且在截止日期之前发现了一些事情，这真的很糟糕。
答案 1 :(得分：12)
是的。
为什么你想要坚持旧的错误和缺乏功能呢？
答案 2 :(得分：5)
这个问题已经回答了，但我会提供2美分。在组织中，更新R应该被视为更新gcc或Java：带警告，临时区域，回滚计划等。其他人的工作和结果可能会受到影响。 [见更新＃2]
我对更新R包更加冲动。只要您可以在任何时间点重现系统状态，就不用担心了。确保夜间备份应该是您的系统管理员的域。
基本思想是你应该能够重现一切。实际测试您的早期结果是否被复制取决于您是否想要反驳您的假设，即没有错误或更改会影响以后的结果。 ：）
更新1.正如在评论及上文中所提到的，在生产环境或任何稳定性最佳的环境中进行更新（例如，错误已知或不重要），引入新错误，新依赖关系，不同输出或任何各种其他软件回归，应该非常谨慎。而且，你在很多事情上都要更新。从R-Forge更新更有可能让您暴露于最新的错误，而不是CRAN。即便如此，我已经发现并报告了CRAN上3个版本的软件包持续存在的错误，以及其他神奇地出现过的回归。我测试了很多，但更新，发现新的错误和调试是我并不总是想（或有时间）进行的努力。
在我使用了很多的新版本的软件包中发现新的错误后，我想起了这个问题。为了检查，我恢复了早期的版本 - 没有更多的崩溃，虽然追查原因花了几个小时，因为我认为这不是在这个包中出现。我不久就会向维护者发送一个注释，这样其他人就不必绊倒同一个bug。
更新2.在一个组织中，我不得不说答案是否定的。实际上，在任何可能存在两个或更多R的并发实例的情况下，盲目地更新包而另一个可能正在使用它们是非常不明智的。 hot-swapping packages, I just don't yet know them可能有很好的方法。请记住，这两个实例只需要共享库（即存储包的位置），而AFAIK不需要在同一台机器上同时运行。因此，如果将库放置在共享系统上，例如，通过NFS，可能无法使用这些库知道R在哪里同时运行。意外杀死另一个R进程通常不是一件好事。
答案 3 :(得分：1)
是的，除非你有充分的理由不这样做（见我对Dirk的评论）
答案 4 :(得分：1)
虽然在之前的答案中已经提到过以下某些内容，但我认为明确一些事情可能会有所帮助。作为开发人员，我认为经常更新软件包（以及R-devel），这是一个很好的做法。你肯定想坚持最新的那里。如果你的软件包import / depends / sugests ...与其他软件包交互，你需要确保每天的互操作性，而不是在发布之前，当时间很短的时候面对'bug'。 另一方面，某些环境将特别强调精确的再现性。在这种情况下，人们可能希望采用更加谨慎的策略进行更新。
但值得强调的是，这两种行为并不是排他性的。可以安装不同版本的R并维护不同的libraries，以便从最前沿的开发环境中获益，并为生产提供更稳定的开发环境。
希望这有帮助。
答案 5 :(得分：0)
我倾向于根据您的需要随时回复，而且从不匆忙！
首先，讨论你在一个你不知道的错误下工作的机会。我觉得这很少见。如果你遇到了一个bug并且有一个更新版本的bug，那么请计划升级。如果需要新功能，请计划升级。如果它是你在圣诞节后的第一天回来并且最大的开销是试图记住你最后做的事情，那么搞乱一些新的依赖性要求（可能包括R之外的系统组件）的开销可能是相对的小，所以考虑看看有哪些更新（猜猜我今天做了什么）; - ）
黄金法则可能是除了对您的使用有意义之外，没有单一的推荐时间表;每日更新将不可避免地导致每次更新更少，从而最大限度地减少实际更新的痛苦，但如果您因为功能的某些变化而不断获得从一天到下一天的不同数值结果，那么它是不值得的。抽样（不同的数字结果困扰了Coursera学生使用插入符号）。不要低估稳定系统的价值，这种系统可以让你继续进行富有成效的工作，而不是费力。