🚧 Attention, peinture fraîche !

Cette page a été traduite par une seule personne et n'a pas été relue et vérifiée par quelqu'un d'autre ! Les informations peuvent par exemple être erronées, être formulées maladroitement, ou contenir d'autres types de fautes.

Vous pouvez contribuer à l'amélioration de cette page sur sa Pull Request.

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 les 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.

Les canaux de diffusion et sauter dans le train

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, qui a été popularisé par Cisco IOS et d'autres projets logiciels. Il y a trois canaux de diffusion pour Rust :

  • Nightly
  • Beta
  • Stable

La plupart des développeurs Rust utilisent principalement le canal stable, mais ceux qui souhaitent essayer les nouvelles fonctionnalités expérimentales utilisent nightly ou beta.

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 beta, mais les tests en beta sur leur système d'Intégration Continue aident à découvrir des potentielles régressions. Pendant ce temps, il continue à 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 beta avant que la régression 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 beta est produite :

nightly: * - - * - - * - - * - - * - - *
                     |
beta:                * - - - - - - - - *

Six semaines après que la première beta soit 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 beta 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:                                *

C'est appelé le “modèle ferroviaire” car toutes les six semaines, une nouvelle publication “quitte la gare”, mais doit encore voyager dans la voie de la beta avant d'arriver en gare de la publication stable.

Rust publie régulièrement toutes les six semaines, réglée 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'il est facile de mettre à jour : si une publication en beta ne fonctionne pas comme prévu, vous pouvez signaler cela à l'équipe et cela sera corrigé avant que la prochaine publication stable 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.

Les 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és. 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 beta 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 sera é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 role 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 toolchains (les publications de Rust et leurs composants associés) que vous avez d'installées. 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 toolchain stable est celle par défaut. La plupart des utilisateurs Rust utilisent celle qui est stable la plupart du temps. Il est possible que vous souhaitiez utiliser celle qui est stable la plupart du temps, mais que vous souhaitiez utiliser nightly sur un projet particulier, car parce que vous vous intéressez à une fonctionnalité expérimentale. Pour pouvoir faire cela, vous pouvez utiliser rustup override dans le dossier de ce projet pour régler rustup pour qu'il utilise la toolchain nightly lorsque vous vous trouvez dans ce dossier :

$ cd ~/projets/necessite-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 utile lorsque vous avez beaucoup de projets Rust !

Le processus de RFC et les Ă©quipes

Donc, comment en apprendre plus 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 de RFC pour améliorer Rust, et les propositions sont examinées et débattues 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 “Les 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.