Branch cut 0.88 : suivre la stabilisation, pas seulement le numéro

Le 7 septembre est la date prévue pour isoler le cycle React Native 0.88. Un numéro présent dans une nightly et une version distribuable en production ne représentent pourtant pas le même niveau de maturité.

Lire les canaux de publication

La présentation des releases React Native (nouvelle fenêtre) distingue les canaux de publication et les phases de support. Les candidates servent à obtenir des retours pendant la stabilisation, tandis qu’une nightly suit un état de développement.

Il faut donc enregistrer la version exacte testée, pas seulement écrire « RN next ». Un tag peut bouger entre deux installations. Sans lockfile et identifiant de build, deux personnes peuvent penser reproduire le même problème avec des dépendances différentes.

Commencer par la compilation native

Un essai de candidate doit d’abord démontrer qu’une configuration représentative compile sur les deux plateformes. Ensuite viennent les comportements : ouverture de l’app, navigation, intégrations système et reprise après arrière-plan.

Les projets avec patches locaux ou modules natifs maison peuvent profiter de cette phase pour repérer leurs dépendances aux API internes. Documenter une incompatibilité avant la stable donne du temps pour préparer un correctif ou contacter le mainteneur.

Garder une décision réversible

La branche d’essai peut vivre à côté de la branche produit. Elle doit produire une liste de blocages et de reproductions, plutôt qu’une accumulation de changements sans lien avec l’upgrade.

Une candidate qui fonctionne sur un écran simple donne un signal encourageant. La décision de migration dépend encore des bibliothèques réellement utilisées et des parcours difficiles à reconstruire après une release : authentification, données locales et notifications. Le calendrier organise cette vérification ; il ne la remplace pas.