Annexe G - Comment Rust est conçu et « Rust Nightly »
Cette annexe explique comment Rust est conçu et comment cela vous affecte en tant que développeur Rust.
La stabilité sans la stagnation
En tant que langage, Rust se soucie énormément de la stabilité de votre code. Nous voulons que Rust soit une fondation solide comme le roc sur laquelle vous pouvez construire, et si les choses changeaient constamment, ce serait impossible. En même temps, si nous ne pouvons pas expérimenter de nouvelles fonctionnalités, nous risquons de ne découvrir des défauts importants qu’après leur publication, lorsqu’il n’est plus possible de les modifier.
Notre solution à ce problème est ce que nous appelons “la stabilité sans la stagnation”, et notre principe directeur est le suivant : vous ne devriez jamais avoir à craindre de passer à une nouvelle version de Rust stable. Chaque mise à jour devrait être indolore, mais devrait aussi vous apporter de nouvelles fonctionnalités, moins de bogues et des temps de compilation plus rapides.
Tchou, tchou ! Les canaux de publication et le modèle du train
Le développement de Rust fonctionne selon un calendrier de train. C’est-à-dire que tout le développement est effectué dans la branche principale du dépôt Rust. Les publications suivent un modèle de train de publication logiciel, qui a été utilisé par Cisco IOS et d’autres projets logiciels. Il existe trois canaux de publication pour Rust :
- Nightly
- Beta
- Stable
La plupart des développeurs Rust utilisent principalement le canal stable, mais ceux qui veulent essayer de nouvelles fonctionnalités expérimentales peuvent utiliser nightly ou beta.
Voici un exemple du fonctionnement du processus de développement et de publication : supposons que l’équipe Rust travaille sur la publication de Rust 1.5. Cette publication a eu lieu en décembre 2015, mais elle nous fournira des numéros de version réalistes. Une nouvelle fonctionnalité est ajoutée à Rust : un nouveau commit arrive sur la branche principale. Chaque nuit, une nouvelle version nightly de Rust est produite. Chaque jour est un jour de publication, et ces publications sont créées automatiquement par notre infrastructure de publication. Ainsi, au fil du temps, nos publications ressemblent à ceci, une fois par nuit :
nightly: * - - * - - *
Toutes les six semaines, il est temps de préparer une nouvelle publication ! La branche beta du dépôt Rust se sépare de la branche principale utilisée par nightly. Maintenant, il y a deux publications :
nightly: * - - * - - *
|
beta: *
La plupart des utilisateurs de Rust n’utilisent pas activement les versions beta, mais testent avec la version beta dans leur système d’intégration continue pour aider Rust à découvrir d’éventuelles régressions. Entre-temps, il y a toujours une publication nightly chaque nuit :
nightly: * - - * - - * - - * - - *
|
beta: *
Disons qu’une régression est trouvée. Heureusement que nous avons eu le temps de tester la version beta avant que la régression ne se glisse dans une version stable ! Le correctif est appliqué à la branche principale, de sorte que nightly est corrigé, puis le correctif est rétroporté sur la branche beta, et une nouvelle version beta est produite :
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
Six semaines après la création de la première beta, il est temps pour une publication stable ! La branche stable est produite à partir de la branche beta :
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
Hourra ! Rust 1.5 est terminé ! Cependant, nous avons oublié une chose : comme les six semaines se sont écoulées, nous avons aussi besoin d’une nouvelle beta de la prochaine version de Rust, la 1.6. Donc après que stable se sépare de beta, la prochaine version de beta se sépare à nouveau de nightly :
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
C’est ce qu’on appelle le “modèle du train” car toutes les six semaines, une publication “quitte la gare”, mais doit encore effectuer un voyage à travers le canal beta avant d’arriver en tant que publication stable.
Rust publié une nouvelle version toutes les six semaines, comme une horloge. Si vous connaissez la date d’une publication de Rust, vous pouvez connaître la date de la suivante : c’est six semaines plus tard. Un avantage agréable d’avoir des publications programmées toutes les six semaines est que le prochain train arrive bientôt. Si une fonctionnalité manque une publication particulière, il n’y a pas lieu de s’inquiéter : une autre arrivera dans peu de temps ! Cela aide à réduire la pression pour glisser des fonctionnalités potentiellement non finalisées juste avant la date limite de publication.
Grâce à ce processus, vous pouvez toujours essayer la prochaine version de Rust et vérifier par vous-même qu’il est facile de la mettre à jour : si une version beta ne fonctionne pas comme prévu, vous pouvez le signaler à l’équipe et obtenir un correctif avant la prochaine publication stable ! Les problèmes dans une version beta sont relativement rares, mais rustc reste un logiciel, et les bogues existent.
Durée de maintenance
Le projet Rust prend en charge la version stable la plus récente. Lorsqu’une nouvelle version stable est publiée, l’ancienne version atteint sa fin de vie (EOL). Cela signifie que chaque version est prise en charge pendant six semaines.
Les fonctionnalités instables
Il y à un autre aspect important de ce modèle de publication : les fonctionnalités instables. Rust utilise une technique appelée “feature flags” pour déterminer quelles fonctionnalités sont activées dans une publication donnée. Si une nouvelle fonctionnalité est en cours de développement actif, elle arrive sur la branche principale, et donc dans nightly, mais derrière un feature flag. Si vous, en tant qu’utilisateur, souhaitez essayer la fonctionnalité en cours de développement, vous le pouvez, mais vous devez utiliser une version nightly de Rust et annoter votre code source avec le flag approprié pour l’activer.
Si vous utilisez une version beta ou stable de Rust, vous ne pouvez utiliser aucun feature flag. C’est la clé qui nous permet d’obtenir une utilisation pratique des nouvelles fonctionnalités avant de les déclarer stables pour toujours. Ceux qui souhaitent opter pour les toutes dernières nouveautés peuvent le faire, et ceux qui veulent une expérience solide comme le roc peuvent rester sur stable en sachant que leur code ne cassera pas. La stabilité sans la stagnation.
Ce livre ne contient que des informations sur les fonctionnalités stables, car les fonctionnalités en cours de développement changent encore, et elles seront certainement différentes entre le moment où ce livre a été écrit et celui où elles seront activées dans les versions stables. Vous pouvez trouver la documentation des fonctionnalités réservées à nightly en ligne.
Rustup et le rôle de Rust Nightly
Rustup facilite le passage entre les différents canaux de publication de Rust, que ce soit globalement ou par projet. Par défaut, vous aurez Rust stable installé. Pour installer nightly, par exemple :
$ rustup toolchain install nightly
Vous pouvez également voir toutes les toolchains (versions de Rust et composants associés) que vous avez installées avec rustup. Voici un exemple sur l’ordinateur Windows de l’un des auteurs :
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
Comme vous pouvez le voir, la toolchain stable est celle par défaut. La plupart des utilisateurs de Rust utilisent stable la plupart du temps. Vous pourriez vouloir utiliser stable la plupart du temps, mais utiliser nightly sur un projet spécifique, parce qu’une fonctionnalité de pointe vous intéresse. Pour ce faire, vous pouvez utiliser rustup override dans le répertoire de ce projet pour définir la toolchain nightly comme celle que rustup doit utiliser lorsque vous êtes dans ce répertoire :
$ cd ~/projects/needs-nightly
$ rustup override set nightly
Désormais, chaque fois que vous appelez rustc ou cargo à l’intérieur de ~/projects/needs-nightly, rustup s’assurera que vous utilisez Rust nightly, plutôt que votre Rust stable par défaut. C’est très pratique quand vous avez beaucoup de projets Rust !
Le processus RFC et les équipes
Alors comment se renseigner sur ces nouvelles fonctionnalités ? Le modèle de développement de Rust suit un processus de Request For Comments (RFC). Si vous souhaitez une amélioration dans Rust, vous pouvez rédiger une proposition, appelée RFC.
N’importe qui peut écrire des RFC pour améliorer Rust, et les propositions sont examinées et discutées par l’équipe Rust, qui est composée de nombreuses sous-équipes thématiques. Il y à une liste complète des équipes sur le site web de Rust, qui inclut des équipes pour chaque domaine du projet : conception du langage, implémentation du compilateur, infrastructure, documentation, et plus encore. L’équipe appropriée lit la proposition et les commentaires, rédige ses propres commentaires, et finalement, un consensus est atteint pour accepter ou rejeter la fonctionnalité.
Si la fonctionnalité est acceptée, une issue est ouverte sur le dépôt Rust, et quelqu’un peut l’implémenter. La personne qui l’implémente peut très bien ne pas être celle qui a proposé la fonctionnalité en premier lieu ! Lorsque l’implémentation est prête, elle arrive sur la branche principale derrière un feature gate, comme nous l’avons discuté dans la section « Les fonctionnalités instables ».
Après un certain temps, une fois que les développeurs Rust qui utilisent les versions nightly ont pu essayer la nouvelle fonctionnalité, les membres de l’équipe discutent de la fonctionnalité, de son fonctionnement sur nightly, et décident si elle doit intégrer Rust stable ou non. Si la décision est d’aller de l’avant, le feature gate est supprimé, et la fonctionnalité est désormais considérée comme stable ! Elle prend le train vers une nouvelle publication stable de Rust.