Annexe G : comment Rust est construit, et “Nightly Rust”
Cette annexe va expliquer comment Rust est construit et comment cela vous impacte en tant que développeur Rust.
La stabilité sans stagnation
En tant que langage, Rust se soucie beaucoup de la stabilité de votre code. Nous voulons que Rust soit une solide fondation sur laquelle vous pouvez construire, et si les choses changent constamment, cela serait impossible. En même temps, si nous ne pouvions pas expérimenter de nouvelles fonctionnalités, nous ne pourrions pas découvrir des défauts importants avant leur publication, ce qui serait trop tard pour changer les choses.
Notre solution à ce problème est ce que nous appelons la “stabilité sans stagnation”, et notre ligne directrice est la suivante : vous ne devriez jamais craindre de passer à nouvelle version de Rust stable. Chaque mise à jour devrait être facile, et devrait aussi vous apporter de nouvelles fonctionnalités, moins de bogues et un temps de compilation plus rapide.
Tchou-tchou ! Les canaux de diffusion et sauter dans les trains
Le développement de Rust suit un planning ferroviaire. Ce que cela veut dire, c’est que tout le développement est fait sur la branche master du dépôt de Rust. Les publications suivent le modèle de trains de publication de programmes, modèle qui a été popularisé par Cisco IOS et d’autres projets logiciels. Il y a trois canaux de diffusion pour Rust :
- Nightly
- Bêta
- Stable
La plupart des développeurs Rust utilisent principalement le canal stable, mais ceux qui souhaitent essayer les nouvelles fonctionnalités expérimentales peuvent utiliser nightly ou bêta.
Voici un exemple du fonctionnement du processus de développement et de publication : supposons que l’équipe de Rust travaille sur la publication de Rust 1.5. Cette publication a été faite en décembre 2015, et nous permet de nous appuyer sur des numéros de version réalistes. Une nouvelle fonctionnalité a été ajoutée à Rust : un nouveau commit est arrivé sur la branche master. Chaque nuit, une nouvelle version nightly de Rust est produite. Chaque jour voit une nouvelle publication, et ces publications sont créées automatiquement par l’infrastructure de publication. Ainsi, les publications ressemblent à ceci, une fois par nuit :
nightly: * - - * - - *
Tous les six semaines, c’est le moment de préparer une nouvelle publication ! La branche beta du dépôt Rust est alors dérivée de la branche master utilisée par nightly. Ainsi, il y a deux canaux de publications :
nightly: * - - * - - *
|
beta: *
La plupart des utilisateurs Rust n’utilisent pas activement les publications en bêta, mais ils testent la bêta sur leur système d’Intégration Continue pour aider à découvrir de potentielles régressions. Pendant ce temps, il continue à y avoir une publication nightly chaque nuit :
nightly: * - - * - - * - - * - - *
|
beta: *
Imaginons qu’une régression soit trouvée. C’est alors une bonne chose que nous ayons du temps pour tester la publication bêta avant que la régression ne se retrouve dans une publication stable ! La correction est alors appliquée sur master, ainsi nightly est corrigé, et ensuite la correction est reportée sur la branche beta, et une nouvelle publication de bêta est produite :
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
Six semaines après que la première bêta a été créée, c’est le moment de publier une version stable ! La branche stable est produite à partir de la branche beta :
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
Youpi ! Rust 1.5 est sorti ! Cependant, nous avons oublié quelque chose : comme les six semaines sont passées, nous devons aussi publier une nouvelle bêta de la version suivante de Rust, la 1.6. Donc après que la branche stable soit dérivée de la beta, la prochaine version de la branche beta doit à nouveau être dérivée de nightly :
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
Ceci s’appelle le “modèle ferroviaire” car toutes les six semaines, une nouvelle publication “quitte la gare”, mais doit encore voyager dans la voie de la bêta avant d’arriver en gare de la publication stable.
Rust publie régulièrement toutes les six semaines, c’est réglé comme une montre. Si vous savez la date d’une publication Rust, vous savez la date de la suivante : elle aura toujours lieu six semaines plus tard. Un des avantages d’avoir des publications planifiées toutes les six semaines est que le train suivant arrive rapidement après. Si une fonctionnalité n’est pas intégrée à une publication, il n’y a pas à s’inquiéter : une autre arrive bientôt ! Cela aide à réduire la pression pour faire passer en toute discrétion des fonctionnalités éventuellement inachevées à l’approche de la date limite de diffusion.
Grâce à ce processus, vous pouvez toujours découvrir la prochaine compilation de Rust et constater par vous-même qu’elle est facile à mettre à jour : si une publication en bêta ne fonctionne pas comme prévu, vous pouvez signaler cela à l’équipe et cela sera corrigé avant que la prochaine publication stable ne soit produite ! La dégradation d’une version bêta est plutôt rare, mais rustc reste un logiciel, et les bogues peuvent exister malgré tout.
Période de maintenance
Le projet Rust prend en charge la version stable la plus récente. Quand une nouvelle version stable est publiée, l’ancienne version atteint sa fin de vie (end of life : EOL). Ceci implique que chaque version est prise en charge pendant six semaines.
Fonctionnalités instables
Il reste une surprise avec ce modèle de publication : les fonctionnalités instables. Rust utilise une technique qui s’appelle les “drapeaux de fonctionnalités” pour déterminer quelles fonctionnalités sont activées dans une publication donnée. Si une nouvelle fonctionnalité est en développement actif, elle va atterrir sur master, et ainsi, dans nightly, mais derrière un drapeau de fonctionnalité. Si vous, en tant qu’utilisateur, souhaitez essayer la fonctionnalité en cours de développement, vous pouvez, mais vous devez utiliser une publication nightly de Rust et annoter votre code source avec le drapeau approprié pour l’activer.
Si vous utilisez une publication bêta ou stable de Rust, vous ne pouvez pas utiliser de drapeaux de fonctionnalités. C’est la clé qui permet d’obtenir une utilisation pratique avec les nouvelles fonctionnalités avant que nous les déclarions stables pour toujours. Ceux qui souhaitent activer ces fonctionnalités expérimentales peuvent le faire, et ceux qui souhaitent avoir une expérience plus solide peuvent s’en tenir au canal stable et leur code ne sera pas cassé. C’est la stabilité sans stagnation.
Ce livre contient uniquement des informations sur des fonctionnalités stables, car les fonctionnalités en cours de développement sont toujours en train de changer, et elles seront sûrement différentes entre le moment où ce livre a été écrit et lorsqu’elles seront activées dans les compilations stables. Vous pouvez trouver la documentation pour les fonctionnalités uniquement pour nightly en ligne.
Rustup et le rôle de Rust nightly
Rustup facilite les changements entre les différents canaux de publication de Rust, de manière globale ou par projet. Par défaut, vous avez Rust stable d’installé. Pour installer nightly, vous pouvez saisir, par exemple :
$ rustup toolchain install nightly
Vous pouvez aussi voir avec rustup toutes les chaînes d’outils (les publications de Rust et leurs composants associés) que vous avez aussi installées avec rustup. Voici un exemple d’un ordinateur sous Windows d’un des auteurs du livre :
> 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 constater, la chaîne d’outils stable est celle par défaut. La plupart des utilisateurs Rust utilisent stable la plupart du temps. Il est possible que vous souhaitiez utiliser stable la plupart du temps, mais que vous souhaitiez utiliser nightly sur un projet particulier, parce que vous vous intéressez à une fonctionnalité expérimentale. Pour ce faire, vous pouvez utiliser rustup override dans le répertoire de ce projet pour configurer rustup pour qu’il utilise la chaîne d’outils nightly lorsque vous vous trouvez dans ce répertoire :
$ cd ~/projects/needs-nightly
$ rustup override set nightly
Maintenant, à chaque fois que vous faites appel à rustc ou cargo à l’intérieur de ~/projets/necessite-nightly, rustup va s’assurer que vous utilisez Rust nightly, plutôt que votre Rust stable par défaut. C’est très pratique lorsque vous avez beaucoup de projets Rust !
Le processus de RFC et les équipes
Donc, comment en savoir plus sur ces nouvelles fonctionnalités ? Le modèle de développement de Rust suit le processus de Request For Comments (RFC). Si vous souhaitez avoir une amélioration de Rust, vous pouvez rédiger une proposition, qu’on appelle une RFC.
N’importe qui peut écrire des RFCs pour améliorer Rust, et les propositions sont examinées et débatues par l’équipe de Rust, qui est composée de nombreuses sous-équipes spécialisées dans différents domaines. Voici une liste complète des équipes sur le site web de Rust, qui comprend des équipes pour chaque aspect du projet : la conception du langage, l’implémentation du compilateur, de l’infrastructure, de la documentation, et plus encore. L’équipe appropriée lit la proposition et les commentaires, écrit quelques commentaires la concernant, et finalement, un consensus se crée pour accepter ou rejeter la fonctionnalité.
Si la fonctionnalité est acceptée, un ticket est ouvert sur le dépôt de Rust, et quelqu’un peut l’implémenter. La personne qui l’implémente ne peut pas être celle qui a proposé la fonctionnalité ! Lorsque l’implémentation est prête, elle atterrit sur la branche master derrière un drapeau de fonctionnalité, comme nous l’avons vu dans la section “Fonctionnalités instables”.
Au bout d’un moment, une fois que les développeurs Rust qui utilisent les publications nightly ont pu tester la nouvelle fonctionnalité, les membres de l’équipe vont discuter de la fonctionnalité, de voir comment elle a fonctionné sur nightly, et vont décider si elle doit être publiée sur Rust stable ou non. Si la décision est d’avancer, le drapeau de fonctionnalité est enlevé, et la fonctionnalité est maintenant considérée comme stable ! Elle saute alors dans le train en direction d’une nouvelle publication stable de Rust.