Décider des numéros de version

Question

DUPLICATE

Comment faire les numéros de version?

Bonjour,

Ainsi, j'ai récemment constaté que Groovy était commercialisé dans la version 1.6 et, tout en écoutant le podcast Java Posse, ils commentaient à quel point cette version était si riche qu'elle devrait ont été 2.0 .

Cela m'a fait réfléchir. Les numéros de version sont-ils simplement arbitraires? Je pensais qu'ils avaient un sens mais je suppose que non. Est-ce que tout est basé sur des étapes et que vous définissez projet sur projet?

Comment votre équipe contrôle-t-elle vos numéros de version et vos versions?

Merci d'avance

Answer 1

Faites la distinction entre le contrôle de version pour le marketing et le pour la gestion technique.

Pour le marketing , la réponse est la suivante: "Tout ce que vous voulez que vos clients pensent." Dans ce cas, une "nouvelle version majeure". devrait probablement être accompagné d'un numéro de version majeur.

Sachez également que les clients prudents hésiteront à utiliser "majeur". nouvelles versions jusqu’à ce que le temps soit écoulé et ils l’ont essayé dans un environnement de test. Un "changement de construction" " Cette version est perçue comme ayant des corrections de bugs et d’autres petites choses ne nécessitant pas beaucoup de processus d’installation.

Pour des raisons techniques , la réponse est: "Toutes les informations que vous souhaitez coder pour les développeurs". Il n'y a pas une seule façon correcte de faire cela; cela dépend de vos objectifs.

Peut-être un "majeur" version signifie "changements importants qui pourraient signifier beaucoup de nouveaux bogues". Peut-être un nouveau " build " nombre se produit sur chaque compilation. Peut-être que les balises nocturnes par date sont votre version. Vous pouvez vous baser sur le temps, les cycles Scrum, les jalons, les fonctionnalités, peu importe!!

Answer 2

Ils sont très arbitraires. Beaucoup de gens aiment avoir quelque chose comme

[major].[minor].[release].[revision]

comme leur système de gestion des versions, mais je suis également membre d’entreprises qui ont refusé de publier un produit de marque 1.0 parce que l’un des vice-présidents ne le souhaitait pas. Le marketing peut aussi influencer cela.

Une bonne question à poser pour augmenter la version majeure peut être:

S'il s'agissait d'un produit payant, les clients paieraient-ils pour mettre à niveau vers cette version plus récente?

Si c'est le cas, augmentez le nombre majeur.

Answer 3

MajorRelease.MinorRelease.Hotfix

Answer 4

Les numéros de version sont arbitraires, mais il existe certaines règles (je pense). Les changements ou corrections de bugs très mineurs augmentent généralement de 0.0.1, c’est-à-dire que V1 devient V1.0.1. Les modifications mineures apportées aux fonctionnalités augmentent de 0.1.0 i.e V1.0.1 devient V1.1.0. Les modifications majeures ou les ré-écritures augmentent de 1.0.0, c.-à-d. En V2.

Cela dit, de nombreuses entreprises semblent tenter de convaincre leurs clients que quelque chose d’important a été franchi en augmentant de 1,0,0 alors que des modifications similaires ont été apportées à 0,1,0. De plus, certaines entreprises qui dépendent de contrats de support distribuent des mises à jour 0.1.0 gratuitement, mais facturent les mises à jour 1.0.0.

En outre, IIRC, certains projets tendent à signifier des constructions expérimentales avec des versions impaires et des constructions stables comme des versions paires (V3 est donc dangereux, V4 est stable).

Answer 5

Dans le cas d'une bibliothèque, le numéro de version vous indique le niveau de compatibilité entre deux versions et donc la difficulté d'une mise à niveau.

Une version de correctif de bogue doit préserver la compatibilité binaire, source et de sérialisation.

Les versions mineures signifient différentes choses pour différents projets, mais elles n'ont généralement pas besoin de préserver la compatibilité de la source.

Les numéros de version majeurs peuvent rompre les trois formes.

J'ai écrit davantage sur la justification ici .