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.
la source
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.Réponses:
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:
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.
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:
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.
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.
la source
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:
Cependant, la possibilité d'ajouter des métadonnées est autorisée pour:
Cependant, il est important de noter que le versionnage sémantique est spécifiquement destiné aux logiciels qui déclarent une API publique:
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.
la source