Bases de numérotation des versions? [fermé]
Supposons que j'ai une application web avec quelques fonctions de base. Je veux du marché. Je voudrais donc attribuer un numéro de version - quelque chose comme 0.0.1. Ce que je veux savoir est-il des contraintes qui devraient s'appliquer à ce système de numérotation?
j'Espère que vous avez compris ma question, merci d'avance.
17 réponses
la plupart des endroits utilisent quelque chose comme ceci:
Libération Majeure.Mise À Jour Mineure.Hot Fix.Construire
vos numéros de version ressembleraient à 1.5.0.15,etc.
beaucoup de logiciels libres utilisent un système en trois points: X. Y. Z où
- X est la compatibilité de la rupture de rejets.
- Y est pour les autres versions, les nombres pairs étant stables et les nombres impairs étant instables.
- Z est pour les correctifs.
de cette façon la version 0.28.1 est une version stable avec un correctif et 2.9.0 est une version alpha avec des correctifs zéro.
certaines personnes s'amusent aussi à développer leurs propres plans. Par exemple: Tex qui par chaque communiqué de approxed Pi, avec les numéros de version: 3, 3.1, 3.14, etc.
cela n'a pas vraiment d'importance, tant que vous pouvez utiliser le numéro de version pour identifier vos versions (I. E. soit vous ajoutez le numéro de révision interne de votre système de contrôle source dans le numéro de version), soit vous l'utilisez pour étiqueter vos versions.
Lorsque vous procédez ainsi, vous pouvez utiliser ce numéro comme votre troisième (ou quatrième). Il semble confus si certains produits saute de la version 1.12345 à 2.12346, mais sauter de 1.4.12345 à 2.0.12345 est plus commun.
à Propos de quel nombre pour commencer, je veux juste citer Eric S. Raymond:
Dans le code source fermé du monde, Version 1,0 signifie " Ne touchez pas à ça si vous êtes prudent."; dans le monde open source il lit quelque chose comme "L' les développeurs sont prêts à parier leurs les réputations sur ça."
vous pouvez utiliser tous les nombres que vous voulez dans votre versioning - qui va vous contraindre?
si vous voulez que votre première version soit 0.0.0.0.0.0.0.1, c'est très bien, même si c'est un peu idiot. Si vous voulez que votre première version à être 106.3, vous pouvez le faire aussi, mais c'est un peu plus ridicule.
découvrez le article de Wikipédia sur le Logiciel de gestion des versions pour certaines idées essayées et vraies de schémas réalistes de numérotation des versions.
j'ai toujours utilisé (réécriture).(fonctionnalité ajoutée).(correction de bug).
mais établissez vos propres règles et rendez-les publiques pour que vos utilisateurs les comprennent.
Prendre un coup d'oeil ici. python setuptools a une spécification très intéressante et claire pour la numérotation des versions. Je suis sûr que vous pouvez obtenir quelques conseils très perspicaces de lui.
a ma connaissance, il n'y a pas encore d'agence gouvernementale qui dicte le nombre de versions. Mais ne vous inquiétez pas, je suis sûr qu'il viendra bientôt.
idem pour ceux qui suggèrent une révision majeure-point-mineur -. Mon approche générale est la suivante: les changements majeurs reçoivent une nouvelle version majeure. Comme, si nous avons ajouté des fonctionnalités importantes. Petits changements, comme ajouté quelques petites fonctionnalités de commodité ou un nouveau rapport, obtenir une révision mineure. Les changements de correction de bogue reçoivent une révision.
je éviterait certainement d'appeler votre première version publiée "0.l " pour des raisons de marketing simple: les nombres inférieurs à 1.0 sonnent comme une version préliminaire ou une version bêta. J'ai connu des gens qui appelaient leur première version 2.3 ou quelque chose comme ça juste pour donner l'impression que ça faisait un petit moment pour inspirer plus de confiance, bien que cela me paraisse un peu malhonnête.
comment sur le logiciel qui n'est pas distribué au public comme un webmail code source? pensez-vous que le numéro de build ou de bug est toujours important dans ce cas?
Vous pouvez commencer par prendre un coup d'oeil à l' versioning du logiciel article sur wikipedia, qui donne quelques informations sur les possibilités que vous avez; -)
Il pourrait vous donner quelques idées de ce que vous pourriez faire dans votre cas particulier...
j'ai utilisé
Majeur.Mineur.Publier.Construire 1.02.4.15
et
l'Année.Mois.Date
2009.12.10
mais tout ce qui vous permet de suivre individuellement les versions fonctionnerait. Aussi longtemps que vous êtes cohérent.
Nous utilisons des grands.mineur.révision.construire où révision est la révision SVN et construction est le numéro de construction qui est basé sur la date courante (au format YYDDD où YY c'est l'année et DDD
Avoir la version SVN est incroyablement utile et nous a sauvés plus d'une fois.
les numéros de Version ne sont pas une spécification concrète dans le développement de logiciels.
En d'autres termes, une équipe peut utiliser 1.0.0.0, d'autres peuvent utiliser 1.0.0 et ainsi de suite. Il n'est pas important.
il suffit de choisir quelque chose qui fonctionne pour vous.
typiquement major.minor.revision est la plus simple et la méthode à utiliser. Visual Studio par exemple peut attribuer des numéros de version automatiquement pour vous, comme le peuvent d'autres outils. Donc tout ce que vous devez mettre à jour est la majeur/mineur valeurs. Les numéros de compilation / révision sont mis à jour automatiquement.
il me semble me rappeler que dans les vieux jours (je parle Commodore ici) nous avons utilisé une syntaxe comme publier.version.révision qui pourrait être ajouté avec fix et/ou build, où fix serait habituellement une lettre collée directement à la révision. Ainsi, un nombre entier pourrait lire quelque chose comme:
2.1.44 A. 786
mais comme la plupart l'ont déjà dit, cela n'a pas vraiment d'importance, il n'y a pas de véritable norme pour cela. Utilisez simplement ce que c'est plus pratique pour vous.
après avoir lu beaucoup d'articles/QAs / FAQ/livres, je me suis mis à penser que [MAJOR].[MINEUR.][REV] est le schéma de version le plus utile pour décrire la compatibilité entre la version du projet (schéma de version) pour le développeur, ne pas pour le marketing).
MAJOR les changements sont incompatibles en arrière et nécessitent des changements nom du projet, chemin vers les fichiers, GUIDs, etc.
mineure changes est rétrocompatible. Marque introduction de nouveau caractéristique.
REV pour les corrections de sécurité/bug. La compatibilité ascendante et descendante.
ce schéma versionnant inspiré par libtool gestion des versions de la sémantique et par les articles:
http://www106.pair.com/rhp/parallel.html
NOTE: je recommande également fournir build/date/custom/qualité
Bonjour app v2.6.34banque Nationale, 2011-05-03, beta, de construire 23545 Mais cette info est pas gestion des versions d'infos!!
10.50.1600.1
majeur.mineur.construire.révision
les modifications majeures sont incompatibles en arrière et nécessitent de changer le nom du projet, le chemin vers les fichiers, les GUIDs, etc.
les modifications mineures sont rétrocompatibles. Marquez l'introduction de nouvelles fonctionnalités.
REV pour la sécurité/Correction de bug. La compatibilité ascendante et descendante.
par exemple. Dans SQL server 2008 le numéro de version RTM est 10.00.1600.22 et dans SQL server 2012 la version est 11.00.2100.60
le premier champ est modifié en raison d'un changement dans le nom du projet, c.-à-d. 10 et 11
Dans SQL server 2008 R2 RTM numéro de version est 10.50.1600.1 et Dans la version de SQL server 2008 est 11.00.1600.22
Deuxième champ est modifié en raison de l'introduction de nouvelles fonctionnalités.
troisième champ indiquer build (developed)
Vient champ indique la révision c'est à dire correctifs appliqués...
vous pouvez utiliser n'importe quelle forme de numérotation de version que vous désirez.
je recommande juste d'utiliser quelque chose qui a du sens. majeur.Mineur.La numérotation des révisions est populaire, mais tout schéma de numérotation que vous souhaitez est "valide".
lors du développement de bibliothèques de logiciels,je recommande utilisation du numéro de version pour communiquer le niveau de compatibilité source et binaire entre deux versions.
puisque vous développez une application web, un numéro de version en deux parties est probablement suffisant. La première partie concerne les nouvelles fonctionnalités et la seconde les corrections.