Adam Jackson, responsable de plusieurs versions antérieures du serveur X.Org, dans son rapport à la conférence passer à un nouveau système de numérotation des numéros. Afin de voir plus clairement depuis combien de temps une version particulière a été publiée, par analogie avec Mesa, il a été proposé de refléter l'année dans le premier numéro de la version. Le deuxième numéro indiquera le numéro de série de la version importante pour l'année en question, et le troisième numéro reflétera les mises à jour correctives.
De plus, comme les versions de X.Org Server sont désormais assez rares (X.Org Server 1.20 est sorti il y a un an et demi) et jusqu'à présent activité sur la formation de X.Org Server 1.21, alors que certaines corrections et innovations se sont accumulées dans le code, il est proposé de passer à un modèle planifié pour la formation de nouvelles versions.
La proposition se résume au fait que la base de code sera constamment développée à l'aide d'un système d'intégration continue et que la publication sera un simple instantané de l'état à certaines dates préprogrammées, à condition que tous les tests CI soient réussis.
Des versions importantes, y compris de nouvelles fonctionnalités, devraient être créées tous les 6 mois. Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées, il est également proposé de créer des builds intermédiaires pouvant se brancher automatiquement, par exemple une fois toutes les deux semaines.
Hans de Goede, développeur Fedora Linux chez Red Hat, que la méthode proposée n'est pas sans inconvénients - puisque le serveur X.Org est très dépendant du matériel, il ne sera pas possible de résoudre tous les problèmes via un système d'intégration continue. Par conséquent, il est proposé d'introduire en outre un système d'erreurs de blocage de version, dont la présence retardera la publication automatique, ainsi que d'organiser la formation de versions préliminaires à tester avant la publication. Michael Dänzer, développeur Mesa chez Red Hat, que la méthode proposée est bonne pour les instantanés et les versions candidates, mais pas pour les versions finales stables, notamment en raison de la possibilité d'obtenir une violation de compatibilité ABI dans une version intermédiaire.
Source: opennet.ru