¿Es una buena práctica actualizar los paquetes R a menudo?

Question

Hace poco que comencé a usar R y no estoy seguro de la frecuencia con la que debo actualizar los paquetes instalados (en este momento, estoy usando principalmente ggplot2 y sonajero). Por un lado, es el típico impulso geek tener la última versión :-) Por otro lado, las actualizaciones pueden romper la funcionalidad y, como un principiante de R, no quiero perder el tiempo investigando incompatibilidades de paquetes y reinstalando bibliotecas, es casi seguro No notaría ninguna diferencia con un paquete mejorado.

Con otras aplicaciones tengo un sentido desarrollado a partir de la experiencia sobre la frecuencia de actualización, cuánto esperar entre el lanzamiento de una actualización e instalarlo, y así sucesivamente. Pero estoy en la oscuridad con respecto a R.

Y para ser claros: no estoy hablando de R en sí, sino de sus bibliotecas.

Gracias.

Answer 1

Aquí está mi filosofía: el usuario ingenuo nunca se actualiza. El usuario sofisticado siempre se actualiza. El usuario avanzado actualiza a menudo, pero con cuidado.

La actualización sin sentido no siempre es beneficiosa. Los errores se abren camino en las versiones actualizadas de las bibliotecas R (¡o R sí mismo!), Y usted podría romper su código existente actualizando sin leer el registro de cambios o el historial de compromisos. Por ejemplo, R 2.11 rompió lme4 en OS X ... vale la pena actualizar cuidadosamente y ejecutar demostraciones de paquetes entre lanzamientos. Realmente apesta actualizar una nueva biblioteca o versión R y darse cuenta de que algo se rompió cuando tienes una fecha límite.

Answer 2

Sí lo es.

¿Por qué querría exactamente aferrarse a los errores antiguos y carecer de características?

Answer 3

Sí, a menos que tenga una buena razón para no hacerlo (ver mi comentario a Dirk)

Answer 4

La pregunta ya está contestada, pero voy a ofrecer mis 2 centavos. En una organización, actualizar R debe tratarse como actualizar gcc o Java: con advertencias, con un área de transición, un plan de reversión, etc. El trabajo y los resultados de otros pueden verse afectados. [Ver actualización n. ° 2]

Soy más impulsivo a la hora de actualizar los paquetes de R. Siempre que pueda reproducir el estado de su sistema en cualquier momento, hay poco de qué preocuparse. Asegurar que las copias de seguridad nocturnas ocurran debe ser el dominio de su administrador de sistemas.

La idea básica es que usted debería ser capaz de reproducir todo. En realidad, la prueba de que se reproducen los resultados anteriores depende de si desea refutar su suposición de que no hay errores o cambios que afecten los resultados posteriores. :)

---

actualización 1. Como se ha mencionado en los comentarios y por encima de, la actualización en un entorno de producción o cualquier entorno donde la estabilidad es óptima (por ejemplo, los insectos son conocidos o no significativo), la introducción de nuevos errores, nuevas dependencias , salida diferente, o cualquier variedad de otras regresiones de software, debe hacerse con bastante cuidado. Además, donde estás actualizando importa mucho. Es más probable que la actualización de R-Forge lo exponga a los errores más recientes que CRAN. Aun así, he encontrado e informado errores que persistieron a través de más de 3 versiones de un paquete en CRAN, así como otras regresiones que simplemente aparecieron mágicamente. Pruebo mucho, pero la actualización, la búsqueda de nuevos errores y la depuración es un esfuerzo que no siempre quiero (ni tengo tiempo) emprender.

Me viene a la mente esta pregunta después de encontrar un nuevo error en una nueva versión de un paquete que uso mucho.Solo para comprobarlo, volví a una versión anterior, no más bloqueos, aunque rastrear la causa me llevó un par de horas, porque supuse que no estaba surgiendo en este paquete. Enviaré una nota al mantenedor antes de tiempo, para que otros no tengan que tropezar con el mismo error.

Actualización 2. En una organización, debo decir que la respuesta es no. De hecho, en cualquier caso donde puede haber dos o más instancias concurrentes de R, es muy imprudente actualizar ciegamente los paquetes mientras que otro puede estar usándolos. Es probable que haya buenos métodos para hot-swapping packages, I just don't yet know them. Tenga en cuenta que las dos instancias solo necesitan compartir bibliotecas (es decir, donde se almacenan los paquetes) y, AFAIK, no necesitan ejecutarse al mismo tiempo en la misma máquina. Por lo tanto, si las bibliotecas se colocan en sistemas compartidos, p. a través de NFS, uno puede no saber dónde más se está ejecutando R al mismo tiempo, utilizando esas bibliotecas. Accidentalmente matar a otro R proceso no suele ser una buena cosa.

Answer 5

Aunque algunos de los siguientes han sido mencionados en respuestas anteriores, creo que sería beneficioso hacer algunas cosas explícitas. Como desarrollador, creo que actualizar los paquetes a menudo (y R-devel para el caso) es una buena práctica. Definitivamente quieres quedarte con lo último que hay. Si su paquete import/depends/sugests ... interactúa con otros paquetes, quiere garantizar la interoperabilidad en el día a día, y no enfrentar los 'errores' justo antes del lanzamiento, cuando el tiempo es corto. Por otro lado, algunos entornos pondrán especial énfasis en la reproducibilidad exacta. En ese caso, uno puede querer adoptar una estrategia más cuidadosa con la actualización.

Pero vale la pena enfatizar que estos dos comportamientos no son exclusivos. Es posible instalar diferentes versiones de R y mantener diferentes libraries, para beneficiarse de un entorno de desarrollo de vanguardia y uno más estable para la producción.

Espero que esto ayude.

Answer 6

Me inclinaría a responder tantas veces como lo necesite, ¡y nunca cuando tenga prisa!

En primer lugar, debata las posibilidades de que estés trabajando bajo un error que desconoces. Yo diría que es bastante raro. Si sufres un error y hay una versión más nueva en la que se soluciona el error, planifica una actualización. Si quieres una nueva característica, planifica una actualización. Si es su primer día de regreso después de Navidad y la mayor sobrecarga es tratar de recordar lo que estaba haciendo realmente en ese momento, la sobrecarga de algunos nuevos requisitos de dependencia (que pueden incluir componentes del sistema fuera de R) es relativamente pequeña, así que considere ver qué actualizaciones están disponibles (adivinar qué hice hoy) ;-)

La regla de oro es probable que no haya un solo horario recomendado que no sea el que tiene sentido para su uso; las actualizaciones diarias inevitablemente generarán menos actualizaciones cada vez y, por lo tanto, minimizarán el dolor de la actualización real, pero no vale la pena si obtiene constantemente resultados numéricos diferentes de un día a otro debido a algún cambio en la forma en que una función realiza el muestreo (diferente los resultados numéricos han plagado a los estudiantes de Coursera usando caret). No subestime el valor de un sistema estable que le permite continuar con un trabajo productivo en lugar de un ataque.