Comment fonctionnent les premiers numéros de version pour les nouveaux produits?

J'écris actuellement une petite application de bureau pour un ami, mais je le fais principalement comme une expérience d'apprentissage pour moi-même. Dans le but de s'instruire et de faire les choses de la bonne façon, je veux avoir des numéros de version pour cette application.

Ma recherche a mis en évidence ces résultats connexes

• Quelle «convention de dénomination de version» utilisez-vous?
• Comment faites-vous la version de vos fichiers (numéros de version)
• Forké un projet, où commencent mes numéros de version?

mais aucun d'eux ne traite de la numérotation des alphas, des bêtas, des candidats à la libération, etc. Quelles sont les conventions pour les numéros de version inférieurs à 1.0? Je sais qu'ils peuvent durer quelque temps; par exemple, PuTTY existe depuis au moins une décennie et n'est encore qu'à la version bêta 0.60.

Cela dépend vraiment du projet; certains projets ne publient même pas de version 1.0.

Les développeurs de MAME n'ont pas l'intention de publier une version 1.0 de leur programme émulateur. L'argument est qu'il ne sera jamais vraiment "fini" car il y aura toujours plus de jeux d'arcade. La version 0.99 a été simplement suivie de la version 0.100 (version mineure 100> 99). De la même manière, Xfire 1.99 a été suivi de 1.100. Après 6 ans de développement, eMule n'a même pas encore atteint la version 0.50. ^{Versionnage de logiciels sur Wikipedia}

Une méthode populaire de numérotation des versions (que j'ai commencé à utiliser) est la version sémantique .

Dans ce schéma, les numéros de version et la façon dont ils changent donnent une signification au code sous-jacent et à ce qui a été modifié d'une version à la suivante.

Quelques citations pour vous donner plus d'idées sur son fonctionnement et / ou répondre à certaines de vos questions:

Comment savoir quand publier la version 1.0.0?

Si votre logiciel est utilisé en production, il devrait probablement déjà être 1.0.0. Si vous avez une API stable dont les utilisateurs dépendent, vous devriez être 1.0.0. Si vous vous inquiétez beaucoup de la compatibilité descendante, vous devriez probablement déjà être 1.0.0.

Cela ne décourage-t-il pas un développement et une itération rapides?

La version zéro majeure est une question de développement rapide. Si vous modifiez l'API tous les jours, vous devez toujours être en version 0.xx ou sur une branche de développement distincte travaillant sur la prochaine version principale.

Si même les plus petites modifications incompatibles vers l'arrière de l'API publique nécessitent une version majeure, ne vais-je pas finir très rapidement avec la version 42.0.0?

C'est une question de développement responsable et de prévoyance. Les modifications incompatibles ne doivent pas être introduites à la légère dans les logiciels qui ont beaucoup de code dépendant. Le coût qui doit être engagé pour la mise à niveau peut être important. Le fait de devoir bump les versions majeures pour publier des modifications incompatibles signifie que vous réfléchirez à l'impact de vos modifications et évaluerez le rapport coût / bénéfice impliqué.

Il existe également des règles sur la façon de spécifier les versions "alpha", "beta", etc. Consultez les détails sur http://semver.org/ .

[Modifier] Un autre schéma de numérotation des versions intéressant est celui que MongoDB utilise :

MongoDB utilise les versions impaires pour les versions de développement.

Il existe 3 numéros dans une version MongoDB: ABC

• A est la version principale. Cela changera rarement et signifiera de très grands changements
• B est le numéro de version. Cela comprendra de nombreux changements, y compris des fonctionnalités et des choses qui pourraient briser la compatibilité descendante. Même les Bs seront des branches stables et les B impair seront du développement.
• C est le numéro de révision et sera utilisé pour les bogues et les problèmes de sécurité.

Par exemple:

• 1.0.0: première version GA
• 1.0.x: correction de bogues à 1.0.x - hautement recommandé pour la mise à niveau, très peu de risques
• 1.1.x: version de développement. cela comprendra de nouvelles fonctionnalités qui ne sont pas entièrement terminées et en cours de réalisation. Certaines choses peuvent être différentes de 1.0
• 1.2.x: deuxième version GA. ce sera le point culminant de la version 1.1.x.

Je ne pense pas qu'il existe une "norme" en tant que telle.

Il existe une convention pour les candidats à la sortie qui est généralement "[version] RC 1", etc., selon le nombre de versions que vous pensez pouvoir publier.

Si vous publiez une version très précoce de votre produit - une version qui n'est pas complète - alors vous voudrez peut-être opter pour la version "0". De cette façon, vous pouvez incrémenter la version au fil du temps lorsque vous remplissez votre ensemble de fonctionnalités.

J'utiliserais "Alpha" et "Beta" comme Release Candidate - pour les versions limitées dans le temps pour indiquer que vous pensez que vous êtes sur le point de publier la version complète.

Il y a une page Wikipedia sur la gestion des versions de logiciels . Pour partager des versions antérieures à 1.0, la convention utilisée par Apple et d'autres fonctionne bien: major.minor.maintSrev où S est l'indicateur de stade pour les versions préliminaires: d = développement, a = alpha, b = bêta, rc = candidat à la libération. Votre première version interne pourrait donc être 1.0.0d1.

Pour les révisions entièrement internes, l'horodatage est suffisant.

La plupart du temps, chaque développeur décide de la norme qu'il va utiliser. En général, bien que les nombres à gauche de la virgule décimale indiquent des révisions importantes qui seraient probablement très visibles pour l'utilisateur moyen (c'est-à-dire des changements de fonctionnalité ou d'interface, etc.). Sur le côté droit de la virgule décimale, ce serait un changement / modification / ajout qui n'a pas beaucoup changé la fonctionnalité globale et la conception mais a changé quelque chose au sujet du programme lui-même (c'est-à-dire rendre une fonction plus rapide tout en faisant la même chose ou corrigé) un problème de sécurité). Ensuite, si vous ajoutez des points décimaux supplémentaires, les chiffres à droite de ceux-ci indiqueraient des changements de plus en plus petits (par exemple, corrections de bugs mineurs / problèmes de sécurité, etc.).

Comme d'autres l'ont dit, il ne semble pas y avoir de norme exacte. Notre organisation utilise la notation suivante:

Release 1.0 ---> 2.0 (Une fonctionnalité majeure nouvelle / améliorée ajoutée au produit)

Version 1.0 ---> 1.1 (une fonctionnalité nouvelle / améliorée de niveau moyen ajoutée au produit)

Version 1.0 ---> 1.001 (corrections de bugs)

Le jalon «version 1.0» est très important pour les utilisateurs d'ordinateurs expérimentés, car il implique que le programme est fait et fonctionne comme prévu. Tout dans la version "0.something" implique que les programmeurs eux-mêmes pensent que le programme n'est pas encore terminé .

Vous pouvez conserver les numéros de version "0.1", "0.2" ... pour les principales réalisations de fonctionnalités, puis les sous-définir avec un numéro de version qui est souvent une date et un horodatage suffisamment fins.