La possibilité de modifier la numérotation et la méthode de création des versions d'X.Org Server est à l'étude.

Adam Jackson, responsable de la préparation de plusieurs versions précédentes de X.Org Server, a proposé dans son rapport à la conférence XDC2019 propose de passer à un nouveau système de numérotation des versions. Pour mieux voir depuis combien de temps une version particulière a été publiée, il est suggéré de refléter l'année dans le premier chiffre de la version, le deuxième chiffre indiquant le numéro de la version majeure pour cette année, et le troisième chiffre représentant les mises à jour correctives.

De plus, étant donné que les versions de X.Org Server sortent maintenant assez rarement (X.Org Server 1.20 est sorti il y a un an et demi) et qu'il n'y a pour l'instant pas d'activité observée concernant le développement de X.Org Server 1.21, alors que certaines corrections et nouveautés se sont accumulées dans le code, il est proposé de passer à un modèle de génération planifiée de nouvelles versions.

La proposition consiste à ce que la base de code évolue en permanence en utilisant un système d'intégration continue, et que la version représente une simple instantané de l'état à des dates préalablement définies, à condition que tous les tests CI réussissent.
Des versions majeures, incluant de nouvelles fonctionnalités, devraient être générées tous les 6 mois. Au fur et à mesure de l'ajout de nouvelles fonctionnalités, il est également proposé de créer des versions intermédiaires, qui pourraient être automatiquement branchées, par exemple, tous les quinze jours.

Hans De Goede (Hans de Goede), développeur de Fedora Linux, travaillant chez Red Hat, a souligné, bien que la méthode proposée ne soit pas sans défauts — étant donné que X.Org Server est très lié au matériel, il sera impossible de détecter tous les problèmes via le système d'intégration continue. Il est donc suggéré d'introduire un système d'erreurs bloquantes pour les versions, dont la présence retarderait le déploiement automatique, ainsi que d'organiser la génération de versions préliminaires pour les tests avant la version finale. Michael Dänzer, développeur de Mesa chez Red Hat, a souligné, a déclaré que la méthode proposée est bonne pour les instantanés et les candidats aux versions, mais pas pour les versions stables finales, notamment en raison de la possibilité d'introduire des violations de compatibilité ABI dans une version intermédiaire.

Source : opennet.ru