Comment définir la version d'un logiciel ?

[azertyman64]

Bonjour,

Actuellement sur un projet, je m'interroge sur les versions d'un logiciel. Il me parrait logique que la première version fonctionnelle soit la 1, mais je voit beaucoup de logiciels ayant pour version 0.x.
Si je pars du principe qu'un logiciel a un cahier des charges, une liste des fonctionnalités qu'ils devra accomplir, est-ce que la 1.0 est la première version ayant toutes ces fonctionnalités ? Prenons le projet wine, il est en est à la version 0.9.17. S'il n'est pas en version 1, est-ce parcequ'il ne fait pas encore fonctionner toutes les programmes marchant sous windows 2000, autrement dit son but initial ?

Souvent en informatique, le premier élément d'une liste n'est pas 1 mais 0. Est-ce dans cet esprit que les premières versions des logiciels sont numéro 0 ?

Ainsi, une version nommé « 2.5.21 » pourrait avoir le sens suivant :
- 2e version commerciale
- 5e ajout de fonctionnalité dans la version 2
- 21e défaut corrigé

Au regard de cette définition, voila ce que j'ai compris :
- les premières versions de mon logiciel, qui n'ont donc pas toutes les fonctionnalités que j'ai prévu dans mon cahier des charges seront numérotés 0.x ; à la fois parce qu'elles sont en deça de ce que doit avoir ma version 1.0 ; mais également car ce sont les premières version et que on utilise généralement le 0 pour le repérer. Et pour chaque fonctionnalité rajouté, et bug corrigé on numérote comme dans la définition.
- Dès que mon application a toutes les fonctionnalités prévues initialement, elle arrivera en version 1.0. Et, très logiquement, les fonctionnalités rajoutées seront repéré par les version 1.x.x

Qu'est-ce qui fait que l'application passe en version 2.0 ? Un très gros changement dans la structure du code ? Ou simplement est-ce parceque l'on a pensé à de nouvelles fonctionnalités, qu'on a définies dans un nouveau cahier des charges que la 2.0 devra respecter ?

Enfin, y-a-t'il une "norme" dans la manière de numéroter un logiciel ?

Sinon je peux numéroter à la ubuntu, mois.année ; mais je préfère éviter car on se rendrait compte que je suis flemard

[Smeagoogle]

A une epoque sur framasoft il y' avait une rubrique abecdaire et une rubrique sur linux me semble t'il et dans l'une des deux un article qui expliquait les normes de numerotation du noyau linux ... mais le site a bien evolué depuis et ces rubriques ont semble t'il disparu ...

[obor2]

Bonjour

Personnellement je pense que le système de numérotation des versions est affaire personnelle. Mais l'application des normes aide lorsque l'on cède la continuité du projet à une tierce personne sans avoir à lui expliquer.

Cependant prendre un peu de temps pour définir son propre système de numérotation dans un document annexes des sources remplit le même objectif.

Le but principal d'un tel système est, rappelons-le, de pouvoir retrouver les fonctionnalité propres à une version particulière, de savoir quels bugs y ont étés corrigés. C'est tout autant utile pour les utilisateurs que pour les développeurs. C'est donc un système de classification.

Le fait que le dernier chiffre corresponde au numéro du bug corrigé me semble bien mal choisi si on travaille sur un projet collaboratif. En effet il est possible que plusieurs développeurs travaillent en parallèle à la résolution d'erreurs disctinctes. Lorsqu'un d'eux a fini son travail, est-il logique que l'un d'eux fassent une version? Oui, certes. Mais qu'une heure après un second en refasse un autre? Euh, non. Personnellement, je trouve ça peu vivable. Je préfèrerai la solution de définir une date pour la mise en disponibilité d'une version contenant un lot de corrections.

En ce qui concerne, le numéro de la fonctionnalité. C'est plutôt utile lors de développements concurentiels aux tests. Je veux dire quand les testeurs stressent certaines fonctionnalités alors que d'autres sont en cours d'implémentation. Pour un développeur/testeur, ça peut être utile avec l'utilisation d'un plan de travail. Les fonctionnalités sont séquentialisées (voire regroupées) et le numéro correspondant implicitement définit. Le développeur/testeur a ainsi organisé sont travail.

En ce qui concerne la version principale. Une fois encore c'est affaire de goût. Tu peux considérer que ton travail ne sera jamais fini et que la version 1 ne sera jamais atteinte; que tout n'est que correction et ajout de fonctionnalités. Tu peux même mettre en place un système de support via ces versions. C'était utilisé (c'est toujours utilisé, d'ailleurs) pour savoir si un support est toujours disponible pour une version donnée tout en sachant qu'un client achetait au besoin chaque version et qu'il pouvait avoir une vieille version. Tu peux aussi voir vers un tout autre horizon. Tu peux aussi décidé qu'une "version" est en fait une variante du même programme. Chacune tournant dans un environnement différent - une pour chaque type de processeur ou pour chaque système d'exploitation suportée.

De plus, ça peut aussi dépendre de ton environnement de développement. Je pense surtout au IDE qui mettent en place un tel système (que l'on peut ou non contrôler). C'est une donnée à tenir en compte aussi.

J'ai déjà croisé nombre de façon de coder cette version durant ma carrière avec des bon et des mauvais côtés. Je pécriserai aussi que c'est mon point de vue personnel. Ce que m'incite donc de te dire: "libre à toi". Mais le mieux c'est la provision d'une définition annexe du système de versionning pour éviter toute ambiguïté.

Je sais que je n'ai pas vraiment répondu à ta question; j'espère que tu m'en excuseras. Ce que je peux te suggérer, c'est de prendre contact avec des dévelloppeurs du monde libre et, pourquoi pas, de jeter un oeil sur SourceForge et consors.

J'espère aussi sincèrement que je ne t'ai pas trop embrouillé avec mon blabla et que tu trouveras la manière qui te conviendra le mieux.

Lau

[Invité]

un article paru sur Framasoft: Les noms d’applications

[Smeagoogle]

un article paru sur Framasoft: Les noms d’applications

Merci , je savais bien que c'etait ici que je l'avais lu

[azertyman64]

Merci à tous pour vos réponses.

Personnellement je pense que le système de numérotation des versions est affaire personnelle. Mais l'application des normes aide lorsque l'on cède la continuité du projet à une tierce personne sans avoir à lui expliquer.

Entièrement d'accord sur le fait que c'est personnel, mais je voulais personnellement faire comme les autre

Le fait que le dernier chiffre corresponde au numéro du bug corrigé me semble bien mal choisi si on travaille sur un projet collaboratif. En effet il est possible que plusieurs développeurs travaillent en parallèle à la résolution d'erreurs disctinctes. Lorsqu'un d'eux a fini son travail, est-il logique que l'un d'eux fassent une version? Oui, certes. Mais qu'une heure après un second en refasse un autre? Euh, non. Personnellement, je trouve ça peu vivable. Je préfèrerai la solution de définir une date pour la mise en disponibilité d'une version contenant un lot de corrections.

Sur ce projet je serais tout seul, et je le resterai sans doute ; pour la simple et bonne raison que je me suis fixé de le gérer de a à z (tant le code, que les graphisme ou la doc). Mais je suis d'accord avec le fait que le 3e numéro ne doit pas correspondre à une correction de bug, mais à une série de correction de bug (par exemple tous les bugs d'une partie) : x.y.238 ça le fais moyen

En ce qui concerne, le numéro de la fonctionnalité. C'est plutôt utile lors de développements concurentiels aux tests. Je veux dire quand les testeurs stressent certaines fonctionnalités alors que d'autres sont en cours d'implémentation. Pour un développeur/testeur, ça peut être utile avec l'utilisation d'un plan de travail. Les fonctionnalités sont séquentialisées (voire regroupées) et le numéro correspondant implicitement définit. Le développeur/testeur a ainsi organisé sont travail.

Pour ma part, les fonctionnalités risquent de correspondre à l'ajout de modules (bien que certains modules auront leur notation). Néanmoins je viens de penser à quelque chose : les fonctionnalités et les corrections de bug pourraient ne pas être liés.
Théoriquement après la 1.1.12 on passera à la 1.2.0. Mais si on pars du principe que ce sont les fonctionnalités rajoutés à la version et les bugs corrigé à la version, on passerait de la 1.1.12 à la 2.2.12 et la prochaine correction de bug : 2.2.13.
C'est sans doute cela que je vais faire, car ça permet de suivre la version et non les fonctionnalités.

En ce qui concerne la version principale. Une fois encore c'est affaire de goût. Tu peux considérer que ton travail ne sera jamais fini et que la version 1 ne sera jamais atteinte; que tout n'est que correction et ajout de fonctionnalités. Tu peux même mettre en place un système de support via ces versions. C'était utilisé (c'est toujours utilisé, d'ailleurs) pour savoir si un support est toujours disponible pour une version donnée tout en sachant qu'un client achetait au besoin chaque version et qu'il pouvait avoir une vieille version. Tu peux aussi voir vers un tout autre horizon. Tu peux aussi décidé qu'une "version" est en fait une variante du même programme. Chacune tournant dans un environnement différent - une pour chaque type de processeur ou pour chaque système d'exploitation suportée.

Je pense que je vais m'en tenir avec ce que j'ai dit, en clair 1 cahier des charges par nouvelle version et les versions X.0 correspondent aux versions remplissant ce cahier des charges. Ce qui me ferait commencer à 0.1 (1ere fonctionnalité de la première version ne remplissant pas le cahier des charges de la 1.0). En plus ça reste dans la logique que le premier élément d'une liste est 0.

J'ai déjà croisé nombre de façon de coder cette version durant ma carrière avec des bon et des mauvais côtés. Je pécriserai aussi que c'est mon point de vue personnel. Ce que m'incite donc de te dire: "libre à toi". Mais le mieux c'est la provision d'une définition annexe du système de versionning pour éviter toute ambiguïté.

C'est exactement ce que je fais : je prévois avant. Et d'ailleur, je compte tous prévoir avant sur ce projet, en clair avoir une modélisation béton, etc.
Et puisque je parle de mon appli, je vais dire un petit mot sur la redistribution : elle sera au minimum sous GPL, et peut être d'autre licences (libres évidemment), ce qui fera surement l'objet d'un post ; et tous les documents (documentation, modélisations, etc.) seront redistribués sous licence de libre diffusion.

[obor2]

Au fait, c'est quoi ton projet? Ca pourrait peut-ête nous intéresser? Surtout si c'est sous licence libre?

Enfin, si c'est pas secret d'état

[Maps]

Un article en anglais sur Wikipedia sur le sujet. On y apprend entre autres que :

TeX has an idiosyncratic version numbering system. Since version 3, updates have been indicated by adding an extra digit at the end, so that the version number asymptotically approaches π. The current version is 3.141592. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. TeX developer Donald Knuth has stated that the "absolutely final change (to be made after my death)" will be to change the version number to π, at which point all remaining bugs will become permanent features.

J'aime beaucoup.
Comme quoi, tout est histoire de goût dans la numérotation des versions

[azertyman64]

@Maps
Enorme ce système de numérotation. Je vais faire pareil avec le nombre d'or

@obor2
Mon projet sera en gros un CMS, mais pas axé publication de contenu comme Joomla!, mais gestion de SI.

Il est possible qu'il interesse du monde, car j'ai vu des recherches de logiciel libre sur le forum où il aurait pu correspondre. D'ailleur je le proposerai peut être un jour à framasoft pour le rajouter dans la logithèque.

Le seul hic' pour vous le proposer ou vous en parler plus c'est que je suis encore dans la modélisation/définition du cahier des charges et donc (comme je veux faire les choses proprement) aucune ligne de code n'a été pondue

[Maps]

@Maps
Enorme ce système de numérotation. Je vais faire pareil avec le nombre d'or

C'est OK pour le nombre d'or... Mais attention, e est déjà pris par MetaFont !