Comment faire les numéros de version?
Mon entreprise construit un produit. Il va être versionné par SVN. C'est une webapp, donc il n'y aura jamais de version qui ne comporte pas de fonctionnalités et pourrait donc toujours être étiquetée comme bêta. Mais comme ce sera un produit d'entreprise, je ne veux vraiment pas de "surveillance instable". Alors, comment feriez-vous pour le versioning? La version 1.0 est-elle stable? La date de construction doit-elle être dans le numéro de version? Dites-moi ce que vous en pensez!
[majeur]. [mineur]. [version]. [build]
majeur: Vraiment une décision marketing. Êtes-vous prêt à appeler la version 1.0? L'entreprise considère-t-elle que c'est une version majeure pour laquelle les clients pourraient avoir à payer plus, ou est-ce une mise à jour de la version majeure actuelle qui peut être gratuite? Moins d'une décision de R&D et plus une décision de produit.
mineur: commence à partir de 0 chaque fois que majeur est incrémenté. +1 pour chaque version rendue publique.
release: Chaque fois que vous atteignez un jalon de développement et que vous publiez le produit, même en interne (par exemple pour le contrôle qualité), incrémentez-le. Ceci est particulièrement important pour la communication entre les équipes de l'organisation. Il va sans dire de ne jamais publier deux fois la même "version" (même en interne). Réinitialisez à 0 lors de mineur ++ ou majeur ++.
build: Peut être une révision SVN, je trouve que cela fonctionne le mieux.
x.y.z.g
les incréments en g sont instables. (ou RC) les incréments de z sont stables et signifient des corrections de bogues.
Les incréments de en y sont stables et signifient de nouvelles fonctionnalités.
Les incréments de en x sont stables, version majeure sans compatibilité ascendante à 100%.
J'ai écrit une fois un "guide de style de version" élaboré pour un grand projet à moi. Le projet n'a pas pu se matérialiser, mais le guide de style est toujours disponible en ligne . C'est mon opinion personnelle, c'est peut-être utile (ou inspirant) pour vous.
Attention, c'est un long texte, qui va dans la version des composants contre la version des produits et des trucs comme ça. Il exprime également des opinions fortes sur certains schémas de version populaires dans la communauté OSS, mais je les ai, donc je les exprime. ;-)
Je ne suis pas d'accord avec l'utilisation du numéro de révision de Subversion, par exemple. Vous souhaiterez peut-être maintenir une version publiée tout en poursuivant le développement dans TRUNK, vous allez donc mettre en place une branche de maintenance - et le versionnement de votre numéro de révision descend.
Modifier: En résumé, il fait la distinction entre les fichiers source de version, les composants et le produit global. Il utilise un système de verson x.y séparé pour les composants et le produit, avec une interdépendance agréable entre les deux qui rend le suivi de la version du composant à quelle version du produit trivial. Il explique également comment gérer les cycles alpha/bêta/version/correctif sans casser le système. En fait, c'est un modus operandi pour tout le cycle de développement, vous pouvez donc choisir. ;-)
Edit 2: Comme suffisamment de personnes ont trouvé mon article utile pour en faire une "bonne réponse", j'ai recommencé à travailler sur l'article. PDF et LaTeX sont maintenant disponibles, une réécriture complète comprenant une meilleure langue et des graphiques explicatifs suivra dès que je pourrai trouver le temps. Merci pour vos votes!
Inspirez-vous de Wikipedia: "Versionnage de logiciel"
Une autre option "nouvelle" et "relativement populaire" est Version Sémantique
Résumé:
Étant donné un numéro de version MAJOR.MINOR.PATCH, incrémentez:
- Version MAJEURE lorsque vous apportez des modifications d'API incompatibles,
- Version MINOR lorsque vous ajoutez des fonctionnalités d'une manière rétrocompatible, et
- Version PATCH lorsque vous effectuez des corrections de bogues rétrocompatibles.
Des étiquettes supplémentaires pour les métadonnées de pré-version et de génération sont disponibles en tant qu'extensions au format MAJOR.MINOR.PATCH.
a.b.c.d
Incréments: quand
- d: corrections de bugs
- c: maintenance, par ex. amélioration des performances
- b: nouvelles fonctionnalités
- a: changement d'architecture
L'obligatoire est le plus à gauche, par ex. s'il y a par exemple une nouvelle fonctionnalité et un bug corrigé alors il suffit d'incrémenter b.
Sur la base de mon expérience de la gestion complexe des dépendances au niveau de la plate-forme d'entreprise et du versionnage des versions, je suis venu recommander une approche que j'aime appeler Versioning semi-sémantique .
Fondamentalement, il s'appuie sur Semantic Versioning 2. mais n'est pas aussi strict.
Segments de version semi-sémantique:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Format du segment de version principal:
MARKETTING.MAJOR.MINOR.PATCH
Chaque segment doit autoriser les caractères alphanumériques, mais les chiffres purs sont recommandés pour les modifications incrémentielles logiques.
Comme SemVer, je recommande les composants majeurs, mineurs et correctifs pour représenter les niveaux de compatibilité inverse, mais je recommande également d'ajouter un Composante marketing . Cela permet aux propriétaires de produits, aux épopées/groupes de fonctionnalités et aux préoccupations commerciales de contourner le composant principal indépendamment des problèmes de compatibilité technique.
Contrairement à d'autres réponses, je ne recommande pas d'ajouter un numéro de build au segment principal. Au lieu de cela, ajoutez un segment post-version après un '+' (ex: 1.1.0.0 + build.42). SemVer appelle ces métadonnées de build, mais je pense que le segment post-version est plus clair. Ce segment est idéal pour déclarer les données du suffixe comme non liées aux informations de compatibilité dans le segment de publication principal . Vos builds d'intégration continue peuvent alors recevoir le numéro de version précédent ajouté avec un numéro de build incrémentiel qui se réinitialise après chaque version principale (ex: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Certaines personnes aiment alternativement mettre le numéro de révision svn ici ou le git commit sha pour le rendre facile à lier au référentiel de code. Une autre option consiste à utiliser le segment post-version pour les correctifs et les correctifs, alors il pourrait être utile d'envisager d'ajouter un nouveau composant de version principale pour cela. Il peut toujours être supprimé lorsque le composant de correctif est incrémenté, car les versions sont effectivement alignées à gauche et triées.
En plus des segments de version et de post-version, les utilisateurs souhaitent souvent utiliser un segment de pré-version pour indiquer des pré-versions presque stables comme les alphas, bêtas et libérer les candidats. L'approche SemVer de cela fonctionne bien, mais je recommande de séparer les composants numériques des classificateurs alphanumériques (ex: 1.2.0.0 + alpha.2 ou 1.2.0.0 + RC.2). Normalement, vous bumpez le segment de version en même temps que l'ajout du segment de post-version, puis supprimez le segment de pré-version lorsque vous les bumpez ensuite le segment de version principale (ex: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Des segments de pré-version sont ajoutés pour indiquer que la version de sortie arrive, généralement juste un ensemble fixe de fonctionnalités pour des tests et un partage plus approfondis qui ne changent pas d'une minute à l'autre en fonction de plus de validations.
La beauté d'avoir tout cela sémantiquement défini d'une manière qui couvre presque tous les cas d'utilisation est que vous pouvez les analyser, les trier, les comparer et les incrémenter de manière standard. Ceci est particulièrement important lorsque vous utilisez des systèmes CI pour des applications complexes avec beaucoup de petits composants versionnés indépendamment (comme des micro-services) chacun avec leurs propres dépendances gérées.
Si vous êtes intéressé, j'ai écrit n analyseur semi-sémantique en Ruby . Je devais non seulement utiliser ce modèle, mais être capable de gérer d'autres applications qui l'utilisaient.
Les "numéros de version" relèvent de votre système de contrôle de version interne. Les numéros de version sont une question différente (et devraient être différents).
Tenez-vous à un système de publication MAJOR.MINOR simple (comme la v1.27), où MAJOR est le niveau de compatibilité (la version 2.x est incompatible avec ou au moins très différente de la version 1.x) et MINOR est vos versions de correction de bogues ou améliorations mineures . Tant que vous suivez le format X.Y, vous pouvez également utiliser d'autres systèmes comme YEAR.MONTH (2009.12) ou YEAR.RELEASE (2009.3). Mais en réalité, il vaut mieux s'en tenir à MAJOR.MINOR, sauf si vous avez une bonne raison de ne pas le faire.
N'utilisez absolument rien qui ne correspond pas au format X.Y, car cela rendra difficile la collaboration des distributions, des sites d'annonces, etc., et cela seul pourrait sérieusement affecter la popularité de votre projet.
Utilisez des branches et des balises dans votre système de contrôle de version (de préférence distribué) pour marquer les numéros de version internes spécifiques comme se rapportant respectivement à MAJORS et MINORS.
Et oui, 1.0 devrait être stable. Toutes les versions doivent être stables, sauf si elles sont marquées alpha, bêta ou RC. Utilisez Alphas pour connu-cassé et incomplet. Bêtas pour cassé connu. RC pour "essayez-le; vous remarquerez probablement des choses que nous avons manquées". Tout ce qui en est dépourvu (idéalement, bien sûr) devrait être testé, bien connu, avoir un manuel à jour, etc.
Si c'est en SVN, alors pourquoi ne pas utiliser le numéro de révision SVN?
Si vous regardez en bas à droite de cette page Web, vous verrez le numéro de version de Stack Overflow qui est le numéro de révision SVN.
Il est assez populaire de nos jours d'utiliser simplement le numéro de révision de Subversion.
La gestion des versions dépend de vous; Je mettrais 1.0 sur la première version en laquelle j'étais confiant. Vous voudrez peut-être le suivre rapidement avec d'autres versions, car certains éditeurs de logiciels ont donné à 1.0 une mauvaise réputation.
Vous voulez un moyen de lier le numéro de version à la construction exacte utilisée, mais vous voulez probablement qu'il soit agréable et simple pour vos utilisateurs finaux. Pensez à utiliser des numéros de version standard et à étiqueter le référentiel SVN avec le numéro de version inclus.
Bien que le simple fait d'utiliser le numéro de révision de Subversion soit agréable et simple, il supprime les informations du numéro de version. Les utilisateurs pourraient considérer cela comme une mauvaise chose.
Je suppose que votre application Web aura une sorte de procédure de déploiement, de sorte que chaque révision de Subversion ne soit pas réellement publiée. Puisqu'il est impossible de "l'extérieur" (du point de vue de l'utilisateur) de déterminer quand les versions sont effectuées et combien de révisions le code subira entre elles, cela rend les nombres presque aléatoires. Ils vont augmenter, et je suppose qu'il est possible de supposer certains sorte de distance de comparer deux révisions, mais pas beaucoup.
Les numéros de version classiques ont tendance à "dramatiser" les versions, afin que les utilisateurs puissent créer une sorte d’attente. Il est plus facile de penser "J'ai la version 1.0, maintenant la version 1.1 ajoute ceci et cela, cela semble intéressant" que de penser "hier, nous avons exécuté SO révision 2587, aujourd'hui c'est 3233, il doit être beaucoup mieux! ".
Bien sûr, cette dramatisation peut également être gonflée, les entreprises choisissant des numéros de version censés sembler plus intéressants que ceux motivés par les différences réelles dans le produit, je suppose que nous allons un peu avec les compteurs de révision.
Schéma de version: [majeur]. [Mineur]. [Devrel] [marque]
[majeur]: incrémentez si vous avez un changement radical de développement.
[mineur]: incrémentez si vous avez un changement mineur dans le développement.
[devrel]: incrémentez si vous avez une correction de bogue. Remise à zéro si major ++ ou minor ++.
[marque]: a, b ou rc: a est une version alpha, b est une version bêta et rc est une version candidate. Notez que des versions comme 1.3.57a ou 1.3.57b ou 1.3.57rc sont antérieures à la version 1.3.57. Commencez à 0.0.0.
Nous avons passé beaucoup trop de temps à décider quand incrémenter la version principale. Certaines boutiques le feraient rarement, vous auriez donc des versions comme 1.25.3 et d'autres le feraient pour toujours, vous donnant 15.0
J'en ai eu marre de ça et j'ai convaincu tout le monde que le numéro de sortie majeur n'est que l'année et que le mineur n'est qu'une sortie séquentielle dans l'année. Les utilisateurs semblaient l'aimer et c'est une évidence de trouver le prochain numéro de version.
Year.Release.build
- année = année en cours
- release = séquence # de versions publiques avec de nouvelles fonctionnalités - réinitialisé à 1 chaque année
- build = incrémenté pour les corrections de bugs et les versions internes
MODIFIER
** Maintenant, c'était pour une application interne qui était continuellement améliorée **
Cela ne fonctionnerait probablement pas pour les applications commerciales où il est important d'avoir des versions majeures à différents moments de l'année à des fins marketing et financières.
J'ai très peu d'expérience dans le domaine. Cependant, voici ce que je ferais:
- Choisissez un schéma de numérotation des révisions et respectez-le. Être cohérent.
- Chaque changement de version doit représenter n changement significatif. La taille d'un changement est significative et les niveaux de changement qui sont reflétés dans le numéro de version dépendent de vous.
Bien sûr, vous pouvez simplement utiliser le numéro de révision svn --- comme beaucoup d'autres l'ont suggéré !!!
J'espère que ça aide.
Nous utilisons une simple syntaxe major.minor.julian_date.
Où;
- major - La première version est 1, puis lorsque nous introduisons de nouvelles fonctionnalités ou modifications majeures si importantes qu'elles ne sont pas rétrocompatibles, augmentez ce nombre.
- minor - Les principaux jalons publiés. Pour chaque build poussé par la production, ce nombre augmente.
- julian_date - Le Julian Day le build a été poussé vers QA.
L'exemple de la première version poussée à QA le 1/15 est -> 1.0.015
L'exemple de la première version mise en production le 3/4 est -> 1.1.063
Ce n'est pas parfait, mais pratique car nous poussons les builds vers QA presque quotidiennement.
Quelques bonnes infos ici:
Quand changer les versions de fichier/d'assemblage
Tout d'abord, les versions de fichier et les versions d'assemblage ne doivent pas nécessairement coïncider. Je recommande que les versions des fichiers changent avec chaque build. Mais, ne modifiez pas les versions d'assembly avec chaque build juste pour pouvoir faire la différence entre deux versions du même fichier; utilisez la version du fichier pour cela. Décider quand changer les versions d'assemblage nécessite une discussion sur les types de builds à considérer: expédition et non-expédition.
Constructions non livrées En général, je recommande de conserver les versions d'assemblage non livrées identiques entre les versions livrées. Cela évite les problèmes de chargement d'assembly fortement nommés en raison de non-correspondances de version. Certaines personnes préfèrent utiliser la stratégie de l'éditeur pour rediriger les nouvelles versions d'assembly pour chaque build. Cependant, je déconseille cela pour les versions non livrées: cela n'évite pas tous les problèmes de chargement. Par exemple, si un partenaire copie x votre application, il ne saura peut-être pas installer la stratégie de l'éditeur. Ensuite, votre application sera interrompue pour eux, même si cela fonctionne très bien sur votre machine.
Mais, s'il existe des cas où différentes applications sur la même machine doivent se lier à différentes versions de votre assembly, je recommande de donner à ces versions des versions d'assembly différentes afin que la bonne pour chaque application puisse être utilisée sans avoir à utiliser LoadFrom/etc.
Envoi de versions Quant à savoir si c'est une bonne idée de changer cette version pour l'envoi de versions, cela dépend de la façon dont vous souhaitez que la liaison fonctionne pour les utilisateurs finaux. Voulez-vous que ces versions soient côte à côte ou en place? Y a-t-il de nombreux changements entre les deux versions? Vont-ils casser des clients? Vous souciez-vous qu'il les brise (ou voulez-vous forcer les utilisateurs à utiliser vos mises à jour importantes)? Si oui, vous devriez envisager d'incrémenter la version Assembly. Mais, encore une fois, considérez que le faire trop de fois peut surcharger le disque de l'utilisateur avec des assemblages obsolètes.
Lorsque vous modifiez les versions de votre assemblage Pour remplacer les versions codées en dur par la nouvelle, je recommande de définir une variable sur la version dans un fichier d'en-tête et de remplacer le codage en dur dans les sources par la variable. Ensuite, exécutez un pré-processeur pendant la génération pour mettre la bonne version. Je recommande de changer les versions juste après l'expédition, pas juste avant, afin qu'il y ait plus de temps pour attraper les bugs en raison du changement.
La raison pour laquelle cette question existe est parce que nous n'avons pas une seule façon convenue de gérer la configuration.
La façon dont j'aime faire le numéro de version est juste un entier incrémenté de 1. Je ne veux pas d'un numéro de version en plusieurs parties que je devrai expliquer ou documenter. Et je ne veux pas utiliser le numéro de rév SVN car cela nécessitera également quelques explications.
Vous auriez besoin de quelques scripts de sortie au-dessus de SVN pour y arriver