Quand dois-je incrémenter le numéro de version?

23

Je n'ai pas appris la programmation à l'école et je ne travaille pas en tant que développeur (professionnel), donc beaucoup de bases ne sont pas très claires pour moi. Cette question tente de clarifier l'un d'entre eux.


Maintenant , supposons que j'ai des problèmes #1, #2et #3dans mon Tracker Les questions qui sont mis à corriger / améliorer pour la version 1.0.0et que la dernière version (STABLE) est 0.9.0.

Quand dois-je passer à la version 1.0.0? Quand a) un seul des problèmes énumérés ci-dessus est fermé ou b) lorsque tous les problèmes liés à la version 1.0sont fermés?

Laquelle est la bonne façon de procéder? Et par la bonne façon, je veux dire ce qui est actuellement utilisé dans l'industrie.

ahmed
la source
22
Voir semver.org
Martijn Pieters
1
Et vous pouvez également inclure les trois problèmes dans votre prochaine version.
Martijn Pieters
Oui, j'utilise déjà SemVer et les trois problèmes sont attendus dans la prochaine version :)
ahmed
J'ai édité la question pour éviter toute confusion.
ahmed

Réponses:

15

Je peux vous dire comment je le fais au travail.

Nous avons un serveur d'intégration continue qui construit, teste, étiquette et génère un package versionné. Nous ne passons à l'étape suivante que si la précédente est réussie à 100%.

Notre version ressemble à ceci: <Major Version>. <Minor Version>. <Build Number>

  • Chaque build réussi qui n'a pas de correction de bogue ou d'amélioration de fonctionnalité terminée incrémente le numéro de build.
  • Chaque version réussie avec un correctif de bogue ou une amélioration de fonctionnalité terminée incrémente la version mineure. Ceci est automatiquement détecté par la présence d'un message de validation utilisant un format particulier. Ce message de validation est également automatiquement tiré dans le projet ChangeLog.
  • Chaque incrément de version majeure est effectué à la main lorsque nous avons des modifications non rétrocompatibles, des réécritures à partir de zéro ou d'autres raisons apportées au cas par cas.
Dietbuddha
la source
Mais si vous avez une série d'améliorations à effectuer sur une <Version mineure>, 1.0.0 par exemple. Devez-vous faire TOUTES ces améliorations pour pouvoir dire "OK! Maintenant, c'est la version 1.0.0" ou vous passez à la version 1.0.0 dès que la première amélioration est terminée?
ahmed
@ahmed J'ai vu l'approche qui 1.4.2est "cet ensemble de correctifs, et tout ce qui est prêt à ce moment-là" ... J'ai également vu 1.4.2comme "Cela sera publié à cette date avec tout ce qui est prêt". Cela dépend de votre cycle de sortie.
5
@ahmed Si le critère pour passer de 0.xx à 1.xx était l'achèvement d'un ensemble de fonctionnalités / correctifs, je n'augmenterais que lorsqu'ils seraient tous terminés. Remarque: nous ne travaillons pas du tout de cette façon. Nous ne ciblons pas une version et décidons des correctifs qui y sont inclus. Nous ciblons les correctifs. La version que nous obtenons est purement pour le suivi et l'identification, pas un objectif.
dietbuddha
C'est exactement ce que je voulais savoir :)
ahmed
21

Les numéros de version ne sont pertinents que pour les versions , car ils permettent aux utilisateurs externes d'identifier une version spécifique de votre logiciel. Si vous êtes juste occupé à faire du développement et à ne pas publier chaque correctif individuellement, ne vous inquiétez pas d'incrémenter le numéro de version pour chaque correctif. Cela ne concerne pas les utilisateurs externes et vous fait perdre votre temps avec la tenue de livres des versions supplémentaires.

Greg Hewgill
la source
Est-ce que cela s'applique également au développement Web où une version peut être un simple correctif pour un bug mineur?
ahmed
4
Faites-vous de l'AQ avant d'émettre le correctif? C'est une version. Si ce n'est pas du produit complet, puis du correctif.
Peter K.
@ahmed Dans un tel scénario, les numéros de version sont souvent invisibles pour l'utilisateur et donc dénués de sens (les numéros de version existent principalement pour le marketing et le support technique, qui ne s'appliquent pas à de nombreuses webapps). L'utilisation de l'ID de validation peut suffire. Si vous insistez pour utiliser des numéros de version, oui, j'augmenterais probablement le niveau de patch.
amon
J'apprends beaucoup de choses ici: p Donc, pour résumer: je n'ai PAS besoin de numéros de version car les ID de validation sont suffisants, car TOUS les utilisateurs utiliseront de toute façon la dernière version.
ahmed
2
Bien que tous les utilisateurs soient sur la même version, au moment où vous examinez le rapport de défaut, la version aura évolué. Vous avez toujours besoin d'un moyen de lier le rapport à une version spécifique du logiciel (la date / heure peut être suffisante).
mattnz
2

Pour les applications Web déployées en continu, nous avons tendance à construire des numéros de build en utilisant symver à l'avant et une queue de numéro de build, c'est-à-dire: 2.5.3.4328 où 4328 provient du système d'intégration continue. L'attente générale est que les nombres changent par étapes délibérées mais que le numéro de build est le véritable ID unique.

Ce qu'il semble faire ici, c'est capturer le jour du déploiement et le numéro de build svn associé:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Pour ce que ça vaut.

Wyatt Barnett
la source
0

Les autres réponses sont déjà excellentes, donc je ne ferai que les ajouter. Si votre logiciel n'est pas publié et que vous n'avez pas vraiment besoin de version publique (la version non publique est votre VCS), ajoutez le mot-clé " SNAPSHOT " à la fin de votre version. Certains systèmes, en particulier dans la gestion des dépendances, traitent les instantanés différemment des versions publiées dans la mesure où ils comparent la date de modification des instantanés au lieu du numéro de version. Donc, si vous aviez un INSTANTANÉ v. 1.0.0 à partir de 8h dans un dépôt de package et qu'un téléchargeur de dépendance local a la même version à partir de 7h, il doit télécharger celui mis à jour à partir du dépôt.

Comme indiqué ci-dessus, votre versioning privé est fourni par votre système de contrôle de version (git, svn etc.).

Hubert Grzeskowiak
la source
0

Il y a assez de choses à dire sur la théorie du versioning, voici un autre point de vue.

Quand dois-je passer à la version 1.0.0?

Je vais concentrer ma réponse sur le changement du numéro de version principal.

Ma réponse est: Fondamentalement, lorsque vous êtes prêt pour cela. Passer de 0,9 à 1,0 est une grande chose, car la perception du public sera que vous passez d'un produit bêta à une version officielle.

(Je vais supposer ici que c'est un produit commercial d'une entreprise).

Quelques questions avant de passer de 0.9 à 1.0.

Votre organisation a-t-elle le temps d'informer tous vos clients actuels. Organiser une fête. Obtenez beaucoup de demandes d'assistance. Un gestionnaire de compte pour vendre votre produit? Etc.

Oui, je vois le versioning comme un outil de marketing et si vous regardez autour de vous, vous voyez que c'est fondamentalement la norme de l'industrie.

Notre société est passée de la version 2.x à 3.0 et a eu une grande fête, a créé beaucoup de buzz et à cause de cela a attiré pas mal de nouveaux clients. Mis à part certaines mises à jour de l'interface, les différences entre les versions étaient assez mineures.

Pieter B
la source