Meilleure pratique: gestion des versions de logiciels
Existe-t-il des directives ou des bonnes pratiques standard sur la version d'un logiciel que vous développez pendant votre temps libre pour le plaisir, mais qui sera néanmoins utilisé par certaines personnes? Je pense qu’il est nécessaire de mettre à jour ce logiciel afin de connaître la version dont on parle (par exemple, pour la correction de bugs, le support, etc.).
Mais où dois-je commencer le contrôle de version? 0.0.0? ou 0.0? Et puis comment incrémenter les nombres? release majeure.minor changement? et ne devrait-on pas s’engager dans un système de contrôle de version être une autre version? ou est-ce seulement pour les versions qui sont utilisées de manière productive?
Vous devriez commencer par la version 1, à moins que vous ne sachiez que la première version que vous "publiez" est en quelque sorte incomplète.
En ce qui concerne l’incrémentation des versions, c’est à vous de décider, mais utilisez la numérotation majeure, mineure, de la construction comme guide.
Il n'est pas nécessaire que chaque version que vous avez validée dans le contrôle de code source soit une autre version. Vous aurez bientôt un très grand numéro de version. Il vous suffit d'incrémenter le numéro de version (d'une manière ou d'une autre) lorsque vous publiez une nouvelle version pour le monde extérieur.
Ainsi, si vous apportez une modification majeure, passez de la version 1.0.0.0 à la version 2.0.0.0 (vous êtes passé de WinForms à WPF par exemple). Si vous effectuez une modification moins importante, passez de 1.0.0.0 à 1.1.0.0 (vous avez ajouté la prise en charge des fichiers png). Si vous apportez une modification mineure, passez de 1.0.0.0 à 1.0.1.0 (vous avez corrigé quelques bugs).
Si vous voulez vraiment avoir des détails, utilisez le nombre final comme numéro de build, ce qui augmenterait à chaque enregistrement/validation (mais je pense que cela va trop loin).
Je voudrais utiliser x.y.z sorte de versioning
x - version majeurey - version mineurez - numéro de build
Je suis essentiellement ce modèle:
partir de 0.1.0
quand il est prêt, je branche le code dans le référentiel source, tag 0.1.0 et crée la branche 0.1.0, la tête/le coffre devient 0.2.0-snapshot ou quelque chose de similaire
J'ajoute de nouvelles fonctionnalités uniquement au coffre, mais les correctifs de backport pour la branche et avec le temps j'en relâche 0.1.1, 0.1.2, ...
Je déclare la version 1.0.0 lorsque le produit est considéré comme complet et ne présente pas d'inconvénient majeur
à 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 fonction, 0-9. Augmentez 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 les nouvelles applications, le numéro de version commence par 1.0.0.
- Si la nouvelle version ne contient que des correctifs de bogues, augmentez le numéro de correctif pour qu'il porte le numéro de version 1.0.1.
- Si la nouvelle version contient de nouvelles fonctionnalités avec ou sans corrections de bogues, augmentez le numéro de fonctionnalité et réinitialisez le numéro de correctif à zéro afin 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ù
- a - majeur (incrémenté à la livraison au client)
- b - mineur (incrémenté à la livraison au client)
- c - révision (incrémentée sur les versions internes)
- d - construction (incrémentée par le régulateur de vitesse)
Il y a aussi le schéma de version de date , par exemple: YYYY.MM, YY.MM, YYYYMMDD
C'est assez informatif 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 (Major.minor.release)
Un autre exemple de l’approche A.B.C est le Eclipse Bundle Versioning . Les bundles 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 traduit une intention différente:
- le segment majeur indique une rupture dans l'API
- le segment mineur indique des modifications "visibles de l'extérieur"
- le segment de service indique les corrections de bugs et le changement de flux de développement
- le segment de qualification indique une construction particulière
Nous suivons une approche a.b.c comme:
incrémentation "a" s’il ya des changements majeurs dans l’application. Comme nous mettons à niveau l'application .NET 1.1 à .NET 3.5
incrémentation 'b' s'il y a quelques modifications mineures telles que tout nouveau CR ou amélioration est mis en œuvre.
incréement 'c' s'il y a quelques défauts corrigés dans le code.
La réponse de base est "ça dépend".
Quel est votre objectif en versioning? Beaucoup de gens utilisent version.revision.build et annoncent seulement version.revision dans le monde entier en tant que version release plutôt que version dev. Si vous utilisez la "version" d'enregistrement, vous constaterez rapidement que vos numéros de version deviennent grands.
Si vous planifiez votre projet, alors j'incrémente la révision des versions avec des modifications mineures et la version incrémentée des versions avec des modifications majeures, des correctifs de bogues ou des fonctionnalités/fonctionnalités. Si vous proposez des versions bêta ou nocturnes, développez le versionnage pour inclure la version et l'incrémenter à chaque version.
Néanmoins, à la fin de la journée, cela dépend de vous et cela doit avoir un sens pour vous.
Comme Mahesh dit: J'utiliserais le type de gestion de version x.y.z
x - version majeure y - version mineure z - numéro de build
vous voudrez peut-être ajouter un datetime, peut-être à la place de z.
Vous incrémentez la version mineure lorsque vous avez une autre version. La version majeure restera probablement à 0 ou à 1; vous la modifiez lorsque vous apportez des modifications majeures (souvent lorsque votre logiciel est à un point où il n'est pas rétrocompatible avec les versions précédentes, ou vous avez modifié l'ensemble de votre infrastructure).
Vous savez que vous pouvez toujours vérifier pour voir ce que font les autres. Les logiciels open source ont tendance à autoriser l'accès à leurs référentiels. Par exemple, vous pouvez diriger votre navigateur SVN vers http://svn.doctrine-project.org et examiner le système de gestion de versions utilisé par un projet réel.
Les numéros de version, les balises, tout y est.
Je commence la gestion de version au plus bas segment (sans correctif). Je ne limite pas ce segment à 10. À moins que vous ne suiviez les générations, vous devez simplement décider quand vous souhaitez appliquer une incrémentation. Si vous avez une phase d’assurance qualité, vous pouvez appliquer une incrémentation au segment le plus bas, puis la prochaine segmentation lorsqu’elle passe l’assurance qualité et est validée. Laissez le segment le plus haut pour les changements de comportement majeur/d'interface utilisateur.
Si vous êtes comme moi, vous ferez un hybride des méthodes afin de suivre le 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 le contrôle qualité/conformité dans le mix. J'ai eu tellement de bêtises autour de la date faisant partie intégrante des versions que je l'ai abandonnée pour une utilisation grand public.
Je ne fais pas le suivi des générations, donc j'aime utiliser le modèle a.b.c sauf si un correctif est impliqué. Lorsque je dois appliquer un correctif, j’applique le paramètre d comme date avec l’heure. J'ai adopté le paramètre temps comme d parce qu'il y a toujours le potentiel de plusieurs dans une journée lorsque les choses explosent vraiment dans la production. J'applique uniquement le segment d (AAAAMMJJHHNN) lorsque je suis en divergence pour un correctif de production.
Personnellement, je ne serais pas opposé à un schéma logiciel va.b revc où c est AAAAMMJJHHMM ou AAAAMMJJ.
Tout ça dit. Si vous pouvez simplement accrocher un outil , configurer et exécuter avec celui-ci vous évitera d'avoir mal à avoir à maîtriser la facette opinion du contrôle de version et vous pourrez simplement dire "utilisez l'outil" ... car tout le monde le processus de développement est généralement donc conforme .