guides

Les noms qui entourent les logiciels de préversion suggèrent une échelle unique, et la plupart des explications placent le nightly sur son barreau du bas. L'image est fausse, et c'est pourquoi on est surpris quand un nightly qu'on appréciait disparaît simplement.

Un build nightly est un instantané de ce qui se trouvait sur la branche principale quand l'horloge a sonné. Il est produit automatiquement, sur un calendrier et non sur une décision, et personne ne l'a jugé prêt pour quoi que ce soit.

Étape contre canal

La distinction qui compte est celle entre une étape et un canal. Une alpha, une bêta ou une release candidate est une étape : elle existe parce qu'une version précise se prépare, et elle se termine quand cette version sort. Un canal nightly n'a pas de destination. Il a produit un build cette nuit, il en produira un ce soir, et il en produira encore longtemps après que la version que vous attendez sera sortie puis oubliée.

C'est pourquoi un nightly n'a pas de numéro de version au sens ordinaire, et pourquoi s'y épingler revient à s'épingler à une date plutôt qu'à une promesse.

Ce que les canaux de Rust rendent visible

Rust rend l'arrangement particulièrement lisible, et il vaut la peine de le lire au pied de la lettre. Sa documentation décrit une nouvelle version nightly produite chaque nuit, créée automatiquement par l'infrastructure de publication. Toutes les six semaines, la branche beta se sépare de cette même branche principale, et six semaines plus tard une version stable est produite depuis beta.

• Étape (alpha, bêta, rc) : existe pour préparer une version précise, et se termine quand elle sort
• Canal (nightly) : produit à heure fixe, n'a pas de destination, ne se termine jamais
• Conséquence : un nightly identifie une date ou un commit, pas une version assortie d'une promesse

Le même commit voyage donc : il atterrit dans nightly le jour de sa fusion, atteint beta à la limite des six semaines suivantes, et devient stable six semaines après. Le canal nightly est le point d'entrée, pas une édition de moindre qualité du produit fini.

Rust s'en sert aussi pour quelque chose qu'un numéro de version ne peut pas exprimer. Les fonctionnalités en développement sont derrière des feature flags qui ne sont disponibles que sur nightly ; sur beta ou stable, elles sont inutilisables. Le canal est donc une frontière de capacités autant que de fraîcheur, ce qui explique que certains projets exigent réellement nightly au lieu d'en tirer un simple avantage.

Ce qui en découle en pratique

Les conséquences pratiques découlent du calendrier. Un nightly peut être cassé d'une façon dont aucune version publiée ne le serait, parce que rien ne l'a filtré. Deux personnes qui font tourner « le nightly » des jours différents font tourner des logiciels différents, si bien qu'un rapport de bogue sur l'un ne veut rien dire sans la date ou le commit. Et un correctif aperçu dans un nightly peut mettre des semaines à atteindre le canal stable, ou être annulé avant d'y arriver.

Rien de tout cela ne rend les nightlies mauvais. Cela en fait un outil différent : le bon pour reproduire un bogue contre la branche principale actuelle, vérifier si quelque chose est déjà corrigé, ou utiliser une fonctionnalité non publiée. Le mauvais pour tout ce que vous devez maintenir en fonctionnement.

Si vous vouliez l'inverse

Si ce que vous voulez est en réalité de la stabilité sur un horizon long, la voie LTS est l'autre extrémité du même axe, et le versionnage sémantique explique ce que les numéros du côté stable promettent.

Le résumé honnête est que nightly n'est pas un label de qualité. C'est une indication sur le moment où le code a été pris, et tout le reste, y compris de savoir s'il fonctionne, est volontairement laissé de côté.