经常更新R包是一种好的做法吗[[关闭]

我的理念是:nave用户从不更新。老练的用户总是更新。超级用户经常更新,但要小心。

lme4 在OSX上。。。在不同版本之间仔细地更新和运行包的演示是值得的。更新到一个新的库或R版本,并在最后期限到来时意识到有些东西坏了,这真的很糟糕。

是的。

问题已经回答了,但我愿意出2美分。在一个组织中,更新R应该像更新 gcc 或 Java :带有警告、暂存区、回滚计划等。其他人的工作和结果可能会受到影响[参见更新#2]

我更喜欢更新R包。只要您可以在任何时间点重现系统的状态,就没有什么可担心的了。确保夜间备份应该是您的系统管理员的域。

更新1。正如上面的评论中所提到的,在生产环境或任何稳定性最佳的环境(例如,已知或不显著的bug)中进行更新,引入新的bug、新的依赖关系、不同的输出或任何其他软件回归,都应该非常小心地进行。更重要的是,你在哪里更新的问题很多。从R-Forge更新比从CRAN更新更容易让您接触到最新的bug。即便如此,我还是发现并报告了CRAN上3+个版本的软件包中存在的bug,以及刚刚神奇地出现的其他回归。我做了很多测试,但是更新、发现新的bug和调试是我不想(或者没有时间)承担的工作。

在一个我经常使用的包的新版本中发现了一个新的bug之后,我想起了这个问题。只是为了检查一下,我恢复到一个早期版本-没有更多的崩溃,虽然追查原因花了几个小时,因为我认为它不是在这个包中出现的。我很快就会给维护人员发一个通知,这样其他人就不必碰到同样的错误了。

hot-swapping packages, I just don't yet know them . 请记住,这两个实例只需要共享库(即包的存储位置),而且,AFAIK不需要在同一台机器上并发运行。因此,如果库被放置在共享系统上(例如通过NFS),那么人们可能不知道在使用这些库的同时R在哪里运行。意外地杀死另一个R进程通常不是一件好事。

是的,除非你有充分的理由不这样做(见我对德克的评论)

尽管在前面的回答中已经提到了以下几点,但我认为明确一些事情可能是有益的。作为一名开发人员,我认为经常更新软件包(对于这一点,使用R-devel)是一种很好的做法。你一定要坚持最新的。如果您的包导入/依赖/建议。。。在与其他软件包交互时,您希望确保日常的互操作性,而不是在发布前遇到“bug”,因为时间很短。 另一方面,有些环境会特别强调精确的再现性。在这种情况下,可能需要采取更谨慎的更新策略。

但值得强调的是,这两种行为并不是排他性的。可以安装不同版本的R并维护不同的 libraries ,以得益于前沿的开发环境和更稳定的生产环境。

我倾向于回应 你需要的时候尽量多,急的时候千万不要 !

首先,讨论一下你在一个你不知道的错误下工作的可能性。我认为这是非常罕见的。如果你正遭受一个bug的困扰,并且有一个更新的版本修复了这个bug,那么就计划升级。如果你想要一个新功能,计划升级。如果这是你圣诞节后回来的第一天,最大的开销是试图记住你上一次实际做了什么,那么处理一些新的依赖性需求(可能包括R之外的系统组件)的开销可能相对较小,所以考虑看看有哪些更新可用(猜猜我今天做了什么);-)

黄金法则