Meilleure pratique: gestion des versions logicielles [fermé]

J'utiliserais x.y.z Type de versioning

x - version majeure
y - mise à jour mineure
z - le numéro de build

Je suis fondamentalement ce modèle:

• Commencer à partir de 0.1.0

• Quand il est prêt, je branche le code dans le repo source, balise 0.1.0 et crée la branche 0.1.0, la tête / tronc devient 0.2.0-snapshot ou quelque chose de similaire

• J'ajoute de nouvelles fonctionnalités uniquement au tronc, mais le backport corrige la branche et avec le temps je la libère 0.1.1, 0.1.2,...

• Je déclare la version 1.0.0 lorsque le produit est considéré comme une fonctionnalité complète et n'a pas les défauts majeurs

• A partir de là-tout le monde peut décider quand incrémenter la version majeure...

J'utilise cette règle pour mes applications:

X. Y. z

Où:

• x = Numéro de version principal, 1 -~.
• y = numéro de caractéristique, 0-9. Augmenter ce nombre si la modification contient de nouvelles fonctionnalités, avec ou sans corrections de bugs.
• z = numéro de correctif, 0-~. Augmentez ce nombre si la modification ne contient que des corrections de bugs.

Exemple:

• pour une nouvelle application, le numéro de version commence par 1.0.0.
• Si la nouvelle version ne contient que des corrections de bugs, augmentez le numéro de correctif afin que le numéro de version soit 1.0.1.
• Si la nouvelle version contient de nouvelles fonctionnalités avec ou sans corrections de bugs, augmentez le numéro de fonctionnalité et réinitialisez le numéro de correctif à zéro pour que le numéro de version soit 1.1.0. Si le numéro de fonctionnalité atteint 9, augmentez le numéro de version principal et réinitialisez le numéro de fonctionnalité et de correctif à zéro (2.0.0 etc)

Nous utilisons A. B. C. D où

• un - grand (incrémenté lors de la livraison au client)
• B-mineur (incrémenté lors de la livraison au client)
• C-révision (incrémentée sur les versions internes)
• D-build (incrémenté par régulateur de vitesse)

Un autre exemple pour l'approche A.B.C est le paquet de VersionsEclipse . Les paquets Eclipse ont plutôt un quatrième segment:

Dans Eclipse, les numéros de version sont composés de quatre (4) segments: 3 entiers et une chaîne nommée respectivement major.minor.service.qualifier. Chaque segment capture une intention différente:

• le segment principal indique une rupture dans L'API
• le segment mineur indique les changements" visibles de l'extérieur "
• le segment de service indique corrections de bugs et changement de flux de développement
• le segment qualificatif indique une construction particulière

Il y a aussi le schéma Date versioning , par exemple: YYYY.MM , YY.MM , YYYYMMDD

Il est assez instructif car un premier regard donne une impression sur la date de sortie. Mais je préfère le schéma X. Y. z, parce que je veux toujours connaître le point exact d'un produit dans son cycle de vie (majeur.mineur.libération)

La réponse de base est "ça dépend".

Quel Est votre objectif en versioning? Beaucoup de gens utilisent la version.révision.construire et seulement annoncer la version.révision au monde car c'est une version de version plutôt qu'une version de dev. Si vous utilisez la "version" d'enregistrement, vous constaterez rapidement que vos numéros de version deviennent volumineux.

Si vous planifiez votre projet, j'incrémenterais la révision pour les versions avec des modifications mineures et incrémenterais la version pour les versions avec des modifications majeures, bug corrections ou fonctionnalités / fonctionnalités. Si vous proposez des versions de type Beta ou nightly build, étendez le versioning pour inclure la version et incrémentez-la à chaque version.

Encore, à la fin de la journée, c'est à vous et il a un sens pour vous.

Comme le dit Mahesh: Je voudrais utiliser X. Y. Z sorte de versioning

X-version majeure y-libération mineure z-numéro de construction

Vous pouvez ajouter un datetime, peut-être au lieu de Z.

Vous incrémentez la version mineure lorsque vous avez une autre version. La version majeure restera probablement 0 ou 1, vous changez cela lorsque vous effectuez vraiment des changements majeurs (souvent lorsque votre logiciel est à un point où il n'est pas rétrocompatible avec les versions précédentes, ou vous avez changé votre intégralité cadre)

Vous savez que vous pouvez toujours vérifier pour voir ce que les autres font. Les logiciels open source ont tendance à permettre l'accès à leurs dépôts. Par exemple, vous pouvez pointer votre navigateur SVN sur http://svn.doctrine-project.org {[2] } et jetez un oeil au système de versioning utilisé par un vrai projet.

Numéros de Version, tags, tout est là.

Nous suivons une approche B. C. Comme:

Increament ' a ' s'il y a des changements majeurs dans l'application. Comme nous mettons à niveau l'application. Net 1.1 vers. net 3.5

Increament ' b ' s'il y a des changements mineurs comme une nouvelle RC ou une amélioration est implémentée.

Increament ' c ' s'il y a des corrections de défauts dans le code.

Je commence à versionner au segement le plus bas (non correctif). Je ne limite pas ce segment à 10. Sauf si vous suivez les builds, il vous suffit de décider Quand vous voulez appliquer un incrément. Si vous avez une phase D'assurance qualité, vous pouvez appliquer un incrément au segment le plus bas, puis au segment suivant lorsqu'il passe L'assurance qualité et est libéré. Laissez le segment le plus haut pour les changements majeurs de comportement / interface utilisateur.

Si vous êtes comme moi, vous en ferez un hybride des méthodes de manière à pour correspondre au rythme de progression de votre logiciel.

Je pense que le modèle le plus accepté A. B. C. ou A. B. C. D surtout si vous avez QA / Compliance dans le mélange. J "ai eu tellement flack autour de la date étant une partie régulière des versions que je l" ai abandonné pour mainstream.

Je ne suis pas les builds, donc j'aime utiliser le modèle A. B. c à moins qu'un correctif ne soit impliqué. Quand je dois appliquer un correctif, j'applique le paramètre d en tant que date avec l'heure. J'ai adopté le paramètre time Comme d car il y a toujours le potentiel de plusieurs dans une journée où les choses explosent vraiment dans la production. Je n'applique que le segment d (YYYYMMDDHHNN) quand je divergent pour un correctif de production.

Personnellement, je ne serais pas opposé à un schéma logiciel de va.B revc où c est AAAAMMJJHHMM ou AAAAMMJJ.

Tout cela dit. Si vous pouvez simplement accrocher un outil pour le configurer et l'exécuter, vous éviterez le mal de tête d'avoir à marshall la facette d'opinion du versioning et vous pouvez simplement dire "utiliser l'outil"... parce que tout le monde dans le processus de développement est généralement , donc conforme.