Quelle version de R faut-il utiliser en production ?

Comprendre les versions de R

Vous le savez sans doute, pour télécharger R il faut se rendre sur le site du CRAN. Vous allez arriver sur la page suivante : https://cran.r-project.org/bin/windows/base/. Et là il suffit de cliquer sur Download R-4.3.0 for Windows pour télécharger l’exécutable puis de l’installer sur votre ordinateur.

À quoi correspond ce numéro : 4.3.0 ?

La plupart des logiciels utilisent un système de versionning. Ils ont un numéro de version qui va évoluer (en général de manière incrémentale) au fil du temps.

Tous les logiciels n’utilisent pas la même méthode pour définir leur numéro de version.

Dans le cas de R, c’est relativement simple :

Le premier chiffre correspond à la version majeure. Il est incrémenté lorsqu’il y a des changements particulièrement importants dans le langage. La dernière fois que c’est arrivé, c’était en 2020 avec la version 4.0.0. Et la fois précédente, c’était en 2013 avec la version 3.0.0. Ça n’arrive pas très souvent.

Le deuxième chiffre correspond à la version mineure. Il est incrémenté lorsque de nouvelles fonctionnalités ou des évolutions sont ajoutées au langage. Dans le monde de R, et c’est un point particulièrement important pour la suite : la version mineure est incrémentée exactement une fois par an, au printemps.

Par exemple :

• Version 4.3.0 en avril 2023
• Version 4.2.0 en avril 2022
• Version 4.1.0 en mai 2021
• Version 4.0.0 en avril 2020
• Version 3.6.0 en avril 2019
• Etc.

Vous pouvez retrouver l’historique des versions de R sur cette page : Previous Releases of R for Windows.

Finalement, le troisième chiffre correspond à la version patch. Ces versions sortent au cours de l’année pour corriger des bugs. En général, un dernier patch correctif sort juste avant la version mineure suivante, donc autour de la fin de l’hiver.

Il n’y a pas de nombre de patchs défini par année, ça dépend surtout de la quantité de bugs et de leur importance. Voici les dates des derniers patchs de ces dernières années :

• Version 4.2.3 en mars 2023 (1 mois avant la version 4.3.0)
• Version 4.1.3 en mars 2022 (1 mois avant la version 4.2.0)
• Version 4.0.5 en mars 2021 (2 mois avant la version 4.1.0)
• Version 3.6.3 en février 2020 (2 mois avant la version 4.0.0)
• Version 3.5.3 en mars 2019 (1 mois avant la version 3.6.0)
• Etc.

Quelle version de R utiliser en production ?

Maintenant que vous savez comment fonctionne le cycle de versions de R, vous pouvez répondre à la question suivante : quelle version de R faut-il utiliser en production ?

Faut-il utiliser la version de R la plus récente ? Non.

La version la plus récente est la version 4.3.0, sortie tout récemment à l’écriture de cet article. Avant le printemps 2024, on va avoir une version 4.3.1, puis 4.3.2, etc. Ces versions supplémentaires ne vont pas apporter de nouvelles fonctionnalités, mais principalement corriger de nombreux bugs présents dans la version 4.3.0.

Le travail sur la version 4.3.1 va commencer très bientôt avec la création d’une version 4.3.0-patched qui va évoluer au fil du temps (jusqu’à la release en 4.3.1). On peut voir la liste des bugs corrigés dans le futur patch sur cette page : R-Patched, puis en cliquant sur le lien “New features in this version”. À l’heure où j’écris cet article, il n’y a rien de plus dans la 4.3.0-patched que dans la 4.3.0 puisque cette dernière est sortie il y a seulement 2 jours.

D’ailleurs, il existe aussi une autre version temporaire appelée R-Devel qui contient les changements de la prochaine version mineure, i.e. la 4.4.0. Si vous êtes curieux, vous pouvez même y trouver la liste des évolutions sur ce lien.

Bon, alors quelle version est-ce qu’on utilise ?

On veut une version récente, stable, et non-buggée.

Le meilleur choix se porte donc sur : Le dernier patch de l’avant-dernière version mineure.

Comme nous sommes actuellement en 4.3.0, il s’agit de la version 4.2.3.

C’est celle qui est recommandée pour un système en production à l’heure actuelle.

Et dès que l’équipe de R sortira la prochaine version mineure, la 4.4.0, alors la version recommandée pour un système en production sera la 4.3.3 (ou 4.3.4, ou 4.3.5, je ne sais pas encore : Ce sera le dernier patch de la série des 4.3.x).

Quand sortira la prochaine version mineure ? Au printemps 2024. Il n’y a pas de date exacte. Comme vous avez pu le voir avec les exemples ci-dessus, parfois c’est en avril, parfois en mai… ça sort quand c’est prêt.

Et quand sortira le dernier patch ? C’est un peu pareil, on ne sait pas tant que la prochaine version mineure n’est pas sortie. Si un patch sort en février, il y a de bonnes chances que ce soit le dernier, mais 2020 nous a prouvé le contraire : 4.0.4 est sorti en février 2020, et quelques semaines plus tard on a vu 4.0.5 apparaître, avec quelques ultimes corrections.

Quand est-ce que je mets à jour ma version de R ?

Si vous avez bien suivi, vous aurez donc compris qu’il existe une version de R recommandée par année :

• R 4.1.3 en 2022
• R 4.0.5 en 2021
• R 3.6.3 en 2020
• Et ainsi de suite…

Quand je dis “en 2022”, j’entends “du printemps 2022 au printemps 2023”.

Vous vous posez sans doute aussi la question : Est-on obligé de mettre à jour R ?

En 2020, j’ai travaillé avec une équipe sur une vieille version de R. Alors qu’on aurait dû être en 3.6.3 (conformément aux recommandations ci-dessus), on était en 3.2.1 : Une version sortie 5 ans plus tôt (en juin 2015) qui en plus n’est pas le dernier patch de sa série. Donc une version buggée.

Quand j’ai mentionné ce problème, on m’a dit que ce serait trop coûteux et trop dangereux de monter de version.

Pas de chance, dans ce projet on n’utilisait pas non plus d’outil de management de versions des packages (comme renv) et on chargeait 40 packages à l’initialisation. Est-ce que les 40 étaient tous nécessaires et utilisés ? Non. Après factorisation, je n’en chargeais plus que 6.

Quel est le problème quand on est dans ce cas de figure ?

Problème 1 : Installer les packages va être de plus en plus difficile

Premièrement, si on n’utilise pas d’outil de management de versions comme renv, on va créer un enfer à tous les nouveaux développeurs qui arrivent sur le projet. Et aux anciens qui déploient sur un nouvel environnement. Et aux personnes de l’IT qui vont s’arracher les cheveux.

Certains vont avoir la version de dplyr de 2015, d’autres celle de 2023. Comment savoir laquelle il faut utiliser ? Bon courage.

Mais même si on utilise renv, on va avoir des complications.

Comme on utilise des packages vieux de 5 ans, ils ne sont plus forcément compatibles avec les dépendances système d’aujourd’hui. Bah oui, les packages dépendent aussi d’outils externes, comme des librairies C++ par exemple. Et là, ce n’est pas garanti que vous ayez la bonne version. Il faudrait donc documenter les bonnes versions des systèmes à utiliser.

Vous commencez à voir le délire ?

Tentative d’installation de car sur R 3.5.1

Prenons un exemple. En ce moment j’utilise la version 3.5.1 avec un client. Essayons d’installer le package car. C’est un package assez classique qui offre plein de fonctions pratiques autour de la régression linéaire. Il est disponible sur le CRAN depuis 2001. Il devrait donc être compatible avec R 3.5.1, non ? Il l’est, puisque sa dernière version indique qu’il faut R 3.5.0 au moins pour l’utiliser. Donc là on est bon. Essayons de l’installer.

install.packages("car")

L’installation échoue très rapidement avec le message : Error: package 'pbkrtest' is not available

Bon. En effet, le package pbkrtest a besoin de R 4.1.0 au moins pour être installé. À la place on va donc installer une version antérieure.

Pour ça je vais utiliser devtools::install_version(), donc je dois installer le package devtools. Il faut espérer que ça marche, sinon on va devoir installer un paquet de dépendances à la main.

Quelle version de pbkrtest on installe ? Soit on télécharge les archives les unes après les autres pour trouver la version la plus récente qui accepte R 3.5.1, soit on fait au pif. Je trouve assez rapidement que l’avant-dernière version convient, donc j’installe celle-ci.

devtools::install_version("pbkrtest", version = "0.5.1")

Aïe : ERROR: dependency ‘lme4’ is not available for package ‘pbkrtest’. On nous dit aussi : package ‘RcppEigen’ is not available (for R version 3.5.1).

Bienvenue dans l’enfer des dépendances. En effet, RcppEigen demande à avoir au moins R 3.6.0. Hop, on recommence. Dans les archives, je trouve une ancienne version compatible avec R 3.5.1 et j’essaie de l’installer :

devtools::install_version("RcppEigen", version = "0.3.3.9.2")

Aïe : ERROR: compilation failed for package ‘RcppEigen’ avec plein de messages d’erreur de C++ où on n’y comprend pas grand-chose. Je vais tenter la version précédente, mais c’est un peu au pif.

devtools::install_version("RcppEigen", version = "0.3.3.9.1")

OK cette fois-ci, ça marche. Bon, on peut retenter l’installation de pbkrtest :

devtools::install_version("pbkrtest", version = "0.5.1")

Cette fois-ci, l’installation de lme4 réussit, et celle de pbkrtest aussi. On peut donc installer car :

install.packages("car")

Oh non… Error: package 'MatrixModels' is not available. Bon on recommence… On trouve une version compatible avec R 3.5.1 et on essaie de l’installer (ça va, vous passez un bon moment ?).

devtools::install_version("MatrixModels", version = "0.5-0")

Ça marche ! On retente car :

install.packages("car")

OUI ! Ça marche !

Ça aura été long. Et là on a juste installé car.

Et surtout, ce n’est pas le seul problème auquel vous ferez face…

Problème 2 : Certaines fonctionnalités ne sont pas disponibles

Vous voulez utiliser une version récente de dplyr ?

Pas de bol, il faut avoir au moins R 3.4.0 (sorti en avril 2017).

Alors oui, il y a encore de la marge si aujourd’hui vous utilisez R 4.1.3. Mais si on extrapole l’évolution de ces dernières années, vous ne pourrez plus suivre les évolutions de dplyr d’ici quelques années.

Et là on parle de dplyr, un package très populaire, en développement actif, qui est à présent en version stable (depuis la 1.0.0).

Pour les packages qui appartiennent au tidyverse, vous pourrez retrouver les versions de R supportées dans cet article : Which versions of R do tidyverse packages support?. D’après leur tableau, avec ma version de R 3.5.1 chez mon client, je n’ai pas accès à la dernière version des packages du tidyverse.

Imaginez à présent que vous souhaitiez utiliser le package Seurat. Pas de chance, il faut au moins R 4.0.0.

Ou bien gtExtras, un exemple peut-être un peu moins exotique, et qui nécessite R 3.6.0.

Bref, vous saisissez l’idée.

Si vous ne mettez pas à jour votre version de R, vous n’aurez sans doute pas de problème l’année prochaine, peut-être pas non plus celle d’après, mais plus vous attendez… et plus vous augmentez le risque.

Et ce n’est pas tout.

Problème 3 : L’internet évolue sans vous

Reprenons l’exemple de dplyr.

Avec le projet de mon autre client qui était coincé en R 3.2.1, j’aurais pu utiliser la version 1.0.2 de dplyr au mieux.

Ça veut dire que quand en 2023 je fais une recherche sur Duckduckgo pour faire une certaine manipulation de données, je vais tomber sur des questions Stackoverflow avec du code qui ne sera pas compatible avec ma version.

On va me proposer la nouvelle version de la fonction summarise (existe depuis dplyr 1.1.0) :

starwars %>%
    summarise(
        mean_height = mean(height), 
        by = c(species, homeworld)
    )

Ce qui ne va pas marcher pour ma version. Ma version utilise encore l’ancienne écriture :

starwars %>%
    group_by(species, homeworld) %>%
    summarise(mean_height = mean(height))

Plus le temps passe, plus le code que je vais trouver sur les internets ne va pas être compatible avec les versions des packages que j’utilise. Si on peut contrôler les versions de tous les logiciels sur un système, on ne peut pas contrôler la version de l’internet qu’on navigue.

Problème 4 : Il faudra bien faire une mise à jour un jour

Imaginons que vous ne fassiez pas de mise à jour.

Le temps passe.

Les contraintes s’accumulent. D’abord légères, ce sont seulement quelques packages qui sont impactés.

Sauf qu’au bout d’un moment… vous n’avez plus le choix.

Vous vous rendez bien compte que travailler avec ces contraintes devient plus coûteux au quotidien que de lancer le chantier de la mise à jour.

Et ce chantier devient monstrueux. Vous n’avez pas de process en place, puisque vous ne l’avez jamais fait avant. Vous mettez à jour brutalement la version de R et celle de tous les packages utilisés, et vous vous retrouvez avec des erreurs partout. La moitié de vos tests ne passent plus.

Le cauchemar.

Ma recommandation : Prévoyez une montée de version une fois par an

On en a déjà discuté : Il y a une version de R recommandée par an (le dernier patch de l’avant-dernière version mineure).

Au printemps de chaque année, peu après la sortie de la nouvelle version mineure, prévoyez une période pendant laquelle vous allez mettre à jour :

• La version de R
• L’ensemble de vos packages utilisés

Certaines parties du code vont sans doute nécessiter une intervention.

Par exemple, au passage vers R 4.0.0, l’option stringsAsFactors a changé sa valeur par défaut. Ce changement a nécessité une attention toute particulière.

Avec le passage en R 4.2.0, les instructions if retournent une erreur si la condition est un vecteur de longueur supérieure à 1, alors qu’on avait seulement un avertissement avant.

Vous allez rapidement remarquer que certains packages, souvent les mêmes, vont apporter des problèmes tous les ans. C’était le cas de dplyr avant le passage en 1.0.0, ou des packages de manipulation de données spatiales (qui vont de toute manière être dépréciés à la fin 2023). Mais il vaut mieux le faire une fois par an, résoudre de petits problèmes souvent, qu’une fois au bout de 5 ans.