Oui, j'ai quelques arguments. Tout d'abord, un panorama des logiciels existants. Si tu regardes l'ensemble des logiciels libres comme propriétaires, tu vois que cette pratique de version paire vs impaire est extrêmement marginale. Sans condamner ce qui est exceptionnel, cela questionne sur la légitimité de la pratique.
Dans le cas de Linux, cette pratique a été introduite à une époque où l'outil de gestion de source des gens modernes était CVS (les gens plus conservateurs utilisaient encore RCS). A cette époque, Linus dumpait toutes les 2 ou 3 semaines un gros tar.gz du noyau que tous les barbus s'empressaient de tester. Il y avait une réelle nécessité de nommer ces dumps de développement et Linus a utilisé une pratique plutôt originale: les versions impaires. Quand le bazar finissait par marchoter, il le passait en version paire. Linus étant un dictateur, personne n'a eu grand chose à discuter quant à la pratique.
Déjà à l'époque, les projets qui utilisaient un gestionnaire de source moderne (CVS donc), n'avaient pas ce besoin puisqu'il suffisait de récupérer la version en cours de développement avec un CVS up et qu'on s'en sortait avec une date.
Linus a fini pour trouver un système de gestion de source qui lui convient et a pu gérer confortablement les différents niveaux de stabilité du noyau avec différents dépotoirs. Il a en toute logique fini par abandonner les versions paires et impaires puisque les raisons qui avaient présidé à leur utilisation n'étaient plus.
Le seul argument qu'on opposait à l'époque où Gnome a fait ce choix que je critique, c'est "si Linux le fait, c'est une bonne pratique, faisons le aussi". J'imagine que ces même supporters de l'époque militent maintenant pour un versionnage classique, comme Linux. Si ce n'était pas le cas, ils seraient en flagrant délit d'incohérence !
Gnome n'est pas le seul projet à s'être posé la question de sa numérotation de version. Je me souviens d'avoir vu ce débat sur kde-core-devel. Récemment sur python-dev, les développeurs ont réfléchi à un autre schéma de sortie et de numérotation de version. Gentoo et Ubuntu ont aussi proposé un nouveau système plutôt basé sur des dates. On voit que Linux et Samba ont abandonné le système des versions paire et impaires, donc il y a clairement eu des discussions sur le sujet. Il y a aussi debian avec ses noms (削除) à la con dont personne ne se rappelle (削除ここまで) parfaitement identifiables.
Dans toutes les discussions auxquelles j'ai assisté, la réflexion sur la numérotation des version est axée pratiquement sur un seul sujet: l'utilisateur.
Les questions qui vont autour:
- comment l'utilisateur va-t-il comprendre quelle version il utilise ?
- comment l'utilisateur distingue les caractéristiques d'une version par rapport à une autre ? Plus stable, plus récente, avec des fonctionnalités en plus, qui plante plus, quelle version signaler dans les rapports de bug, etc
- comment l'utilisateur sait que sa version est à jour ?
- comment communiquer à l'utilisateur un changement important (on casse tout, plus rien de ce qui marchait avant ne marche) ?
Le schéma le plus courant est:
- un numéro de version majeur pour distinguer une famille de version
- un numéro de version mineur pour distinguer une mise à jour avec des nouvelles fonctionnalités
- un sous numéro de version pour distinguer des correctifs sans nouvelle fonctionnalité.
- un vocable particulier pour désigner les versions en cours de développement: instable, preview, alpha, beta, release candidate, demo,
Ce schéma est très courant, donc l'utilisateur "classique" s'y retrouve assez facilement: Python 2.6 est plus récent que Python 2.7, KDE 3 est une évolution majeure de KDE 2, Windows 8 Consumer Preview n'est pas la version finale mais une version en cours de développement, à tester par les utilisateurs et développeurs aventureux. Et Gnome 2.4.3, c'est comme Gnome 2.4.0 mais en plus stable.
Le choix de numérotation des versions instables en impaires embrouille un peu le message vers l'utilisateur. Raisonnablement, un utilisateur qui a un Gnome 2.4 et qui veut passer à la version suivante de Gnome s'attend à passer à la version 2.5 . Il faut alors lui explique que "oui mais non, parce que tu comprends, Gnome la version 2.5, c'est que pour les développeurs et les testeurs, donc c'est directement 2.6". Sans en faire tout un fromage, ça complique quand même le message vis à vis de l'utilisateur. Autre scenario, l'utilisateur vient de passer de Gnome 2.4 à Gnome 2.6 grâce à sa distrib et se dit ben zut, moi qui aime bien avoir la dernière version stable de mes logiciels, j'ai raté Gnome 2.5 .
Alors, pourquoi compliquer le message vis à vis de l'utilisateur ? En particulier pour un logiciel qui se veut accessible au plus grand nombre et pas juste aux barbus ?
De mon point de vue, il n'y a pas de bonne justification. Certes, c'est vaguement plus pratique pour les développeurs et les testeurs, mais ce public est justement capable de s’accommoder d'à peu près n'importe quel schéma de numérotation vu qu'ils sont impliqués dans le projet. Et les outils de gestion de conf modernes (déja avec subversion, encore plus avec git) permettent de gérer cette problématique extrêmement simplement.
Je trouve ça étrange pour Gnome de payer le prix d'une certaine incompréhension des utilisateurs pour un gain que je peine à voir.
[^] # Re: Et pour la numérotation de versions
Posté par Philippe F (site web personnel) . En réponse à la dépêche GNOME 3.4 : l'émergence des applications. Évalué à 4.
Oui, j'ai quelques arguments. Tout d'abord, un panorama des logiciels existants. Si tu regardes l'ensemble des logiciels libres comme propriétaires, tu vois que cette pratique de version paire vs impaire est extrêmement marginale. Sans condamner ce qui est exceptionnel, cela questionne sur la légitimité de la pratique.
Dans le cas de Linux, cette pratique a été introduite à une époque où l'outil de gestion de source des gens modernes était CVS (les gens plus conservateurs utilisaient encore RCS). A cette époque, Linus dumpait toutes les 2 ou 3 semaines un gros tar.gz du noyau que tous les barbus s'empressaient de tester. Il y avait une réelle nécessité de nommer ces dumps de développement et Linus a utilisé une pratique plutôt originale: les versions impaires. Quand le bazar finissait par marchoter, il le passait en version paire. Linus étant un dictateur, personne n'a eu grand chose à discuter quant à la pratique.
Déjà à l'époque, les projets qui utilisaient un gestionnaire de source moderne (CVS donc), n'avaient pas ce besoin puisqu'il suffisait de récupérer la version en cours de développement avec un CVS up et qu'on s'en sortait avec une date.
Linus a fini pour trouver un système de gestion de source qui lui convient et a pu gérer confortablement les différents niveaux de stabilité du noyau avec différents dépotoirs. Il a en toute logique fini par abandonner les versions paires et impaires puisque les raisons qui avaient présidé à leur utilisation n'étaient plus.
Le seul argument qu'on opposait à l'époque où Gnome a fait ce choix que je critique, c'est "si Linux le fait, c'est une bonne pratique, faisons le aussi". J'imagine que ces même supporters de l'époque militent maintenant pour un versionnage classique, comme Linux. Si ce n'était pas le cas, ils seraient en flagrant délit d'incohérence !
Gnome n'est pas le seul projet à s'être posé la question de sa numérotation de version. Je me souviens d'avoir vu ce débat sur kde-core-devel. Récemment sur python-dev, les développeurs ont réfléchi à un autre schéma de sortie et de numérotation de version. Gentoo et Ubuntu ont aussi proposé un nouveau système plutôt basé sur des dates. On voit que Linux et Samba ont abandonné le système des versions paire et impaires, donc il y a clairement eu des discussions sur le sujet. Il y a aussi debian avec ses noms
(削除) à la con dont personne ne se rappelle (削除ここまで)parfaitement identifiables.Dans toutes les discussions auxquelles j'ai assisté, la réflexion sur la numérotation des version est axée pratiquement sur un seul sujet: l'utilisateur.
Les questions qui vont autour:
- comment l'utilisateur va-t-il comprendre quelle version il utilise ?
- comment l'utilisateur distingue les caractéristiques d'une version par rapport à une autre ? Plus stable, plus récente, avec des fonctionnalités en plus, qui plante plus, quelle version signaler dans les rapports de bug, etc
- comment l'utilisateur sait que sa version est à jour ?
- comment communiquer à l'utilisateur un changement important (on casse tout, plus rien de ce qui marchait avant ne marche) ?
Le schéma le plus courant est:
- un numéro de version majeur pour distinguer une famille de version
- un numéro de version mineur pour distinguer une mise à jour avec des nouvelles fonctionnalités
- un sous numéro de version pour distinguer des correctifs sans nouvelle fonctionnalité.
- un vocable particulier pour désigner les versions en cours de développement: instable, preview, alpha, beta, release candidate, demo,
Ce schéma est très courant, donc l'utilisateur "classique" s'y retrouve assez facilement: Python 2.6 est plus récent que Python 2.7, KDE 3 est une évolution majeure de KDE 2, Windows 8 Consumer Preview n'est pas la version finale mais une version en cours de développement, à tester par les utilisateurs et développeurs aventureux. Et Gnome 2.4.3, c'est comme Gnome 2.4.0 mais en plus stable.
Le choix de numérotation des versions instables en impaires embrouille un peu le message vers l'utilisateur. Raisonnablement, un utilisateur qui a un Gnome 2.4 et qui veut passer à la version suivante de Gnome s'attend à passer à la version 2.5 . Il faut alors lui explique que "oui mais non, parce que tu comprends, Gnome la version 2.5, c'est que pour les développeurs et les testeurs, donc c'est directement 2.6". Sans en faire tout un fromage, ça complique quand même le message vis à vis de l'utilisateur. Autre scenario, l'utilisateur vient de passer de Gnome 2.4 à Gnome 2.6 grâce à sa distrib et se dit ben zut, moi qui aime bien avoir la dernière version stable de mes logiciels, j'ai raté Gnome 2.5 .
Alors, pourquoi compliquer le message vis à vis de l'utilisateur ? En particulier pour un logiciel qui se veut accessible au plus grand nombre et pas juste aux barbus ?
De mon point de vue, il n'y a pas de bonne justification. Certes, c'est vaguement plus pratique pour les développeurs et les testeurs, mais ce public est justement capable de s’accommoder d'à peu près n'importe quel schéma de numérotation vu qu'ils sont impliqués dans le projet. Et les outils de gestion de conf modernes (déja avec subversion, encore plus avec git) permettent de gérer cette problématique extrêmement simplement.
Je trouve ça étrange pour Gnome de payer le prix d'une certaine incompréhension des utilisateurs pour un gain que je peine à voir.