Processus de développement d’une version

Chaque distribution ROS 2 passe par un processus de développement de plus d’un an qui commence avant la sortie de la distribution précédente. Vous trouverez ci-dessous une vue d’ensemble de ce processus de développement. Il n’y a pas de date d’échéance spécifique pour les éléments de ce processus, mais en général, les éléments antérieurs doivent être terminés avant que les éléments ultérieurs puissent être terminés.

Pour connaître la progression de ce processus pour une version spécifique, consultez la page de documentation de cette version.

Article	Remarques
Trouvez le patron de ROS	Le « ROS Boss » est la personne chargée de guider une distribution à travers les étapes de développement, de publication, de mise à jour et de fin de vie de sa vie. Ils sont choisis parmi l’équipe interne ROS 2 d’Open Robotics.
Exécuter le processus pour choisir le nom de la distribution	Le ROS Boss organise le processus de choix du nom de la distribution, en utilisant les contributions de sources telles que la communauté et les conflits de nommage potentiels.
Créer la page de documentation de la distribution	Chaque distribution a une page de documentation qui répertorie ses statistiques vitales, telles que la date de sortie prévue, la date de fin de vie et les modifications importantes depuis la version précédente.
Définir le calendrier de publication	Les dernières semaines précédant le jour de la sortie (généralement, la Journée mondiale de la tortue) sont mouvementées et pleines de délais, comme le moment de geler l’implémentation RMW par défaut. Ces délais doivent être planifiés longtemps à l’avance.
Produire une feuille de route	Bien que chaque contributeur à ROS ait ses propres fonctionnalités planifiées pour chaque distribution, nous essayons de maintenir une feuille de route globale des nouvelles fonctionnalités et des changements significatifs que nous prévoyons de voir dans la distribution. Le ROS Boss et le chef de l’équipe de développement ROS 2 chez Open Robotics travaillent en collaboration avec le ROS 2 TSC et d’autres parties intéressées pour produire une feuille de route réalisable dans le temps disponible et répondant aux besoins de la communauté ROS.
Annoncer la feuille de route	La liste des fonctionnalités prévues et des modifications importantes est rendue publique, via un problème GitHub qui permettra de suivre l’avancement du développement de chaque élément de la feuille de route. Bien sûr, cela ne signifie pas que la feuille de route est fixée à ce stade, car les plans de développement peuvent changer et nous accueillons toujours (et le faisons fréquemment) de nouvelles contributions même si elles ne figurent pas sur la feuille de route prévue.
Définir les plates-formes cibles et les principales dépendances	Les plates-formes cibles, en termes de système d’exploitation, de distribution et de version, doivent être définies suffisamment à l’avance pour que les travaux de développement sur l’infrastructure (tels que le support dans la ferme de construction) puissent se poursuivre. De même, les versions de chaque dépendance majeure (quelle version de Python, quel(s) compilateur(s), quelle version d’Eigen, etc.) doivent également être corrigées. Cela se fait via une mise à jour de REP-2000.
Ajouter la prise en charge de la plate-forme à la batterie de builds	La ferme de construction est une partie essentielle de l’infrastructure prenant en charge une distribution ROS 2. Il fournit des fonctionnalités d’intégration continue qui nous aident à maintenir la qualité, et il construit les packages binaires sur lesquels la communauté s’appuie pour éviter de construire ROS 2 et des packages à partir de la source. Si les plates-formes cibles diffèrent de la distribution ROS 2 précédente, la prise en charge nécessaire doit être ajoutée à la batterie de builds.
Logo de la Commission et illustration associée	Une partie bien-aimée de chaque distribution ROS 2 (et distribution ROS !) est le logo. Le logo est commandé à un artiste professionnel en fonction du nom de distribution choisi. Basé sur le logo, d’autres illustrations telles que l’icône turtlesim sont également produites.
Créer une liste de diffusion pour la distribution	Vitale pour faire des annonces critiques, une liste de diffusion doit être mise en place pour contacter les personnes intéressées à savoir quelque chose sur la distribution, par exemple que leur paquet ne parvient pas à être intégré dans un binaire sur la ferme de construction.
Créer des cas de test	Alors que le processus de développement entre dans les derniers mois, les tests commencent sérieusement. Les cas de test d’intégration qui seront utilisés lors des étapes finales de développement doivent être produits et fournis à l’équipe de publication qui sera responsable de leur exécution.
Annoncer le prochain gel du RMW	Le gel RMW est le point auquel l’implémentation RMW par défaut pour la nouvelle distribution est gelée. Cela donne aux développeurs une cible stable pour tester leurs packages, ce qui est particulièrement important pour les développeurs de bibliothèques clientes, qui ont besoin de savoir quelles fonctionnalités de la couche RMW seront disponibles pour être utilisées par les bibliothèques clientes.
Mettre à niveau les packages de dépendance	Les packages dépendant de ROS mais pas du logiciel ROS et non disponibles dans le gestionnaire de packages de la plate-forme (comme aptitude pour Ubuntu), les soi-disant « packages de fournisseurs », doivent être mis à jour vers les versions spécifiées dans REP-2000 (ou une version appropriée , pour ceux qui ne figurent pas dans REP-2000). Ceci est particulièrement important sous Windows.
Créer un plan de lancement détaillé	La planification des deux derniers mois du processus de développement est effectuée. Cela produit un plan de test détaillé, des délais indiquant quand certains packages doivent être disponibles, etc. Il permet de trouver des dépendances entre les étapes du processus de publication et de trouver des personnes pour effectuer chacune de ces étapes.
Geler la RMW	L’implémentation RMW est désormais figée. En théorie, il peut maintenant être testé de manière exhaustive pour s’assurer qu’il fonctionne correctement le jour de la sortie.
Annoncer le gel général à venir	Le prochain gel après le gel de l’implémentation de RMW consiste à geler la distribution dans son ensemble. C’est à ce moment que les packages ROS principaux gèlent les fonctionnalités, ce qui donne aux développeurs de packages non essentiels une cible stable pour tester leurs packages et donne aux testeurs de distribution quelque chose à tester qui ne changera pas juste après l’avoir testé. .
Congeler la distribution	À partir de ce moment, aucune nouvelle fonctionnalité ne peut être ajoutée à l’un des packages ROS de base. Seules les corrections de bogues pour les bogues (inévitables) trouvés lors des phases intensives de test d’intégration du développement peuvent être incorporées dans la base de code. Cela signifie que Rolling Ridley est effectivement gelé, temporairement.
Annoncer la succursale à venir	La ramification de la nouvelle distribution ROS 2 de Rolling Ridley est un moment important. Cela vaut la peine de se préparer.
Annoncer la prochaine bêta	Lorsque la distribution entre en version bêta, elle est prête pour des tests plus larges par la communauté ROS. Cette version bêta se produit peu de temps après que la distribution est dérivée de Rolling Ridely.
Succursale de Rolling Ridley	La nouvelle distribution ROS 2 est créée en créant une nouvelle branche à partir de Rolling Ridley. En effet, la nouvelle distribution naît à ce moment-là. Pendant ce temps, Rolling Ridley est libre du processus de développement et peut continuer dans le futur, recevant à nouveau de nouvelles fonctionnalités.
Ajouter la distribution au CI	Le système d’intégration continue est mis à jour pour permettre la construction à l’aide des branches de la nouvelle distribution et des principaux packages ROS. Cela signifie que les développeurs de packages peuvent exécuter CI pour leurs packages sur la nouvelle distribution, plutôt que sur Rolling Ridley.
Commencer à créer des archives de test provisoires	L’équipe d’élite de testeurs qui mettra la nouvelle distribution à l’épreuve a besoin de quelque chose à tester sans constamment compiler ROS 2 à partir de la source. La ferme de construction est utilisée pour produire un ensemble d’archives contenant la distribution à un moment donné pour que les testeurs la testent.
Ajouter la documentation de distribution	Une documentation détaillée sur la distribution, comme les changements significatifs depuis la distribution précédente, est ajoutée au site de documentation de ROS 2.
Annoncer la version bêta	La version bêta de la distribution est faite et la communauté ROS dans son ensemble est invitée à contribuer à la tester (pour ceux qui ne le font pas déjà). À ce stade, plus il y a de testeurs, mieux c’est, car la distribution doit être soumise à un éventail de scénarios aussi large que possible pour trouver des bogues avant la publication.
Préparations de la version finale	Alors que la nouvelle distribution entre dans une phase absolument complètement gelée, les derniers préparatifs sont faits pour la sortie. Celles-ci incluent des choses comme la production de packages binaires à l’aide de la ferme de construction afin qu’il y ait quelque chose à publier.
Libérer	Le grand jour, qui si tout se passe comme prévu, coïncide avec la Journée mondiale de la tortue le 23 mai. Les packages binaires de la distribution sont mis à disposition dans le référentiel de version et une annonce est faite. Des fêtes sont organisées et l’équipe de développement de ROS 2 prend une pause bien méritée.