La version sémantique autorise-t-elle 4 composants dans les numéros de version?

Tous les exemples de versioning sémantique que j'ai vus montrent 3 composants en cours d'utilisation. Pas plus de 2 caractères de période. Chez $DAYJOB, nous utilisons 4 composants dans nos numéros de version:

5.0.1.2

Le versionnage sémantique le permet-il?

Et en tant que question secondaire de niveau supérieur et plus discutable, est-ce vraiment important? J'ai commencé à penser que ce pourrait être une bonne idée d'appliquer le contrôle de version sémantique, mais finalement des entités comme PCI le remplacent.

J'aurais dû clarifier mon commentaire PCI. Le problème est que les audits et leur coût influencent lorsque les composants majeurs et mineurs changent, pas nécessairement une véritable nouvelle fonctionnalité. Par exemple, si une fonctionnalité liée aux paiements est introduite, nous augmentons le numéro mineur pour PCI. Mais si nous ajoutons une toute nouvelle fonctionnalité liée à quelque chose dans l'interface graphique, ce n'est pas le cas. Seul le patch change. Donc, dans ce cas, nous n'avons pas vraiment notre mot à dire en tant que développeurs, car quelqu'un d'autre prend ces décisions.

Il semble que vous contourniez les conventions normales juste pour éviter les frais généraux / audits de processus. Cela ... me semble inquiétant.

Ce que vous faites est effectivement faire un numéro de version supplémentaire (votre chiffre PCI mineur) un peu intentionnellement afin de déplacer votre fonction / petits numéros de version dos un endroit, pour ne plus déclencher vos critères de vérification interne.

Quoi qu'il en soit, pour en venir à votre question sur le contrôle de version sémantique, la spécification pour le contrôle de version sémantique indique:

Étant donné un numéro de version MAJOR.MINOR.PATCH, incrémentez:

• Version MAJEURE lorsque vous apportez des modifications d'API incompatibles,
• Version MINEURE 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 .

Je souligne.

La question est donc la suivante: utilisez-vous le quatrième caractère pour les métadonnées de pré-version / génération? Ou est-ce essentiellement une autre indication de version que vous publiez?

Si "oui", alors la spécification du versioning sémantique le permet. Si «non», vous ne suivez techniquement pas le versioning sémantique.

Et en tant que question secondaire de niveau supérieur et plus discutable, est-ce vraiment important?

Que vous souhaitiez le suivre de manière rigide ou non est une décision que vous et votre équipe devez prendre. Le but du versioning sémantique est d'aider à la compatibilité des API:

Les corrections de bogues n'affectant pas l'incrémentation de l'API de la version du correctif, les ajouts / modifications d'API rétrocompatibles incrémentent la version mineure et les modifications d'API incompatibles en arrière incrémentent la version principale.

J'appelle ce système «Versioning sémantique». Dans ce schéma, les numéros de version et la façon dont ils changent donnent une signification au code sous-jacent et à ce qui a été modifié d'une version à la suivante.

C'est un système qui permet de rendre plus clair lorsque le contrôle de version affecte les utilisateurs en aval de l'API.

Tant que votre API est tout aussi claire, ce n'est pas une grosse affaire que vous choisissez. Le versioning sémantique se trouve être simple, par exemple si j'utilise 3.4.2 et que je dois passer à 3.4.10, je sais que je peux le faire sans rien casser. Si la nouvelle version est la 3.5.1, je sais qu'elle est rétrocompatible. Et je sais que la version 4.0.1 serait un changement de rupture.

Cela fait partie de la signification des numéros de version.

@enderland Oui, fondamentalement. MAJOR (PCI) .MINOR (PCI) .FEATURE.HOTFIX + BUILD. Nous ne sommes fondamentalement autorisés qu'à modifier les 3e et 4e composants sans impliquer PCI (et par la suite les suzerains PCI de l'entreprise). Pour moi, cela semble un peu artificiel, je ne suis pas sûr qu'ils soient justifiés dans la façon dont ils gèrent le numéro de version, mais je ne connais pas suffisamment le PCI et le processus d'audit pour dire le contraire.

Ok, ça va. Vous avez un système qui fonctionne pour vous et répond à vos besoins. C'est le point du versioning.

Si votre API est privée (uniquement en interne), la façon dont vous versionnez n'a pas d'importance tant que cela a du sens pour vous et pour tous ceux qui l'utilisent. Lorsque le contrôle de version dans un format standard est important, c'est lorsque de nombreux autres utilisateurs de votre API ont besoin de savoir «que signifie cette version?

Le fait d'avoir un système de version arbitraire confondra les personnes habituées à d'autres systèmes, comme le versioning sémantique. Mais si personne n'utilise vraiment votre système de version, sauf les personnes qui le créent - cela n'a pas vraiment d'importance.

Dans la version actuelle de Semantic Versioning, qui est 2.0.0 , non. Il existe une exigence qui définit la version comme la forme XYZ où X, Y et Z sont des entiers non négatifs qui ne contiennent pas de 0 de début:

Un numéro de version normal DOIT prendre la forme XYZ où X, Y et Z sont des entiers non négatifs et NE DOIT PAS contenir de zéros de tête. X est la version majeure, Y est la version mineure et Z est la version patch. Chaque élément DOIT augmenter numériquement. Par exemple: 1.9.0 -> 1.10.0 -> 1.11.0.

Cependant, la possibilité d'ajouter des métadonnées est autorisée pour:

Les métadonnées de construction PEUVENT être indiquées en ajoutant un signe plus et une série d'identificateurs séparés par des points immédiatement après le correctif ou la version préliminaire. Les identificateurs DOIVENT comprendre uniquement des caractères alphanumériques ASCII et un trait d'union [0-9A-Za-z-]. Les identificateurs NE DOIVENT PAS être vides. Les métadonnées de construction DEVRAIENT être ignorées lors de la détermination de la priorité de la version. Ainsi, deux versions qui ne diffèrent que par les métadonnées de génération ont la même priorité. Exemples: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Cependant, il est important de noter que le versionnage sémantique est spécifiquement destiné aux logiciels qui déclarent une API publique:

Les logiciels utilisant la version sémantique DOIVENT déclarer une API publique. Cette API peut être déclarée dans le code lui-même ou exister strictement dans la documentation. Quoi qu'il en soit, il doit être précis et complet.

Cela tend à soutenir le développement de bibliothèques ou de services et non au niveau d'une application.

La chose importante à considérer est la signification de vos numéros de version, à la fois pour une utilisation interne et externe. Les versions ne sont que des identifiants qui vous permettent de parler des différences de logiciel à deux moments différents. Le versionnage sémantique est une méthode pour mettre des règles autour de cela, donc si vous savez qu'une application utilise le versionnage sémantique, vous pouvez plus facilement déterminer le niveau d'effort requis pour mettre à jour vos packages. Suivre une norme commune peut être une bonne chose, mais si vous ne le pouvez pour aucune raison, la documentation des règles pour vos utilisateurs devrait également suffire.