J'ai vu beaucoup de projets utilisant v1.2.3 comme convention de nommage pour les balises dans git. J'ai aussi vu certains utiliser 1.2.3 . Existe-t-il un style officiellement approuvé, ou de bons arguments pour utiliser l'un ou l'autre ?
Version 1.0.0 de Versionnage sémantique par Tom Preston-Werner, célèbre pour GitHub. une sous-spécification en s'occupant de ça :
Spécification d'étiquetage (SemVerTag)
Cette sous-spécification DEVRAIT être utilisée si vous utilisez un système de contrôle de version (Git, Mercurial, SVN, etc.) pour stocker votre code. L'utilisation de ce système permet aux outils automatisés d'inspecter votre paquet et de déterminer la conformité SemVer et les versions publiées.
- Lors du balisage des versions dans un système de contrôle de version, la balise pour une version DOIT être "vX.Y.Z", par exemple "v3.1.0". .
Cependant après discussion ce point a été supprimé, et n'est plus présent dans le document la dernière version de la spécification SemVer (2.0.0 au moment de la rédaction). Un fil de discussion ultérieur au même endroit a été approfondi et a donné lieu à une nouvelle Est-ce que "v1.2.3" est une version sémantique ? être ajouté à la FAQ du site de SemVer master bien qu'à l'heure où nous écrivons ces lignes (plus de deux ans plus tard), ce changement n'a pas encore été effectué. toujours pas présent dans la version officielle de la spécification.
Merci - C'est très proche. J'aurais aimé qu'il soit qualifié pourquoi le site v devrait être là cependant.
Je vois que quelqu'un d'autre a eu la même idée : github.com/mojombo/semver.org/issues/unreads#issue/1
Il semble y avoir deux conventions dominantes (en supposant que vous respectiez également une norme raisonnable pour la numérotation des publications elles-mêmes) :
v1.2.31.2.3Les avantages de v1.2.3 sont que la documentation de Git (et aussi celle de Mercurial) utilise ce format dans ses exemples, et que plusieurs "autorités" telles que les Noyau Linux y Git lui-même l'utiliser. (La mention Versionnage sémantique avait l'habitude de l'utiliser mais ne le fait plus).
Les avantages de 1.2.3 sont que gitweb ou GitHub peuvent offrir automatiquement un téléchargement tarball ou zip de la forme packagename-$tag.tar.gz (et je pense qu'il est tout à fait établi qu'un tarball devrait pas être nommé package-v1.2.3.tar.gz ). Vous pouvez également utiliser git describe directement pour générer les numéros de version de la boîte à outils. Pour les projets légers sans processus de publication formel, ces possibilités peuvent être très pratiques. Il convient également de noter que Semantic Versioning n'est en aucun cas la seule norme ou une norme universellement acceptée pour la numérotation des versions. Des projets notables tels que GNOME, ainsi que d'innombrables autres projets, utilisent la norme 1.2.3 la dénomination des balises.
Je pense qu'il est probablement trop tard pour consolider ces positions. Comme toujours, soyez cohérent et soyez logique.
Mise à jour : Comme mentionné dans ce GitHub propose désormais le nom d'une archive avec le "v" supprimé de la balise.
En ce qui concerne GitHub et la génération de tarball : ce n'est plus pertinent. Ils enlèvent le 'v' de l'étiquette.
Le préfixe "v" est également très utile pour trier les balises par ordre alphabétique. D'autres balises peuvent également exister, que ce soit officiellement dans un dépôt maître ou pour suivre le travail d'un développeur localement. Avec le préfixe 'v', les balises de version forment leur propre groupe, au lieu d'être dispersées dans le reste de l'espace de nommage.
La raison du "v" précédent est historique. Les anciens SCCS (cvs, rcs) ne pouvaient pas faire la distinction entre un identifiant de balise et un numéro de révision. Les identifiants de balises ne devaient pas commencer par une valeur numérique afin que les numéros de révision puissent être détectés.
+1 : Bonne première réponse et un nom tiré d'un de mes livres préférés :-) Mais peut-être que votre prochaine réponse portera sur une question plus actuelle.
... mais si cela est seulement vrai pour plus vieux SVCS, si le but de cette réponse était une question sur le Git moderne ?
Conseils aux nouveaux gestionnaires de paquets pour marquer les versions sans préfixe v (comme compositeur pour les projets PHP). SemVer 2.0 n'a rien à voir avec la spécification des balises. C'est fait intentionnellement pour éviter les conflits. Cependant, c'est conseillé pour ajouter le préfixe v dans la documentation et les références textuelles. Comme exemple de format v1.0.4 au lieu d'un plein version 1.0.4 o ver. 1.0.4 est suffisamment verbeux et élégant dans la documentation.
"il est conseillé de " Conseillé par qui, et où peut-on voir ce conseil dans son contexte original ?
@bignose Regardez comment packagist ou maven central analyse le repos git. Il est préférable d'utiliser uniquement des chiffres, mais avec la version 1.xx, le 'v' est supprimé. Je crois qu'il y en a beaucoup d'autres, y compris pour debian/ubuntu. Packagist avait un article indiquant qu'ils préféraient l'étiquette numérique dans git et le préfixe 'v' dans la documentation, mais je ne peux pas le trouver maintenant.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
25 votes
Avec 43 upvotes et plus, je me demande si cette question très précieuse ne pourrait pas être reformulée et rouverte, avec une réponse intégrant tous les points dans un joli résumé et se trouvant en haut ? La réponse de @PeterEisentraut semble être la plus complète, alors que la réponse acceptée par ATM semble un peu trompeuse. (Je pense que je vais moi-même utiliser la v1.2.3 pour les balises, après avoir lu tous les points).
1 votes
SO est pour fixer le code. Les meilleures pratiques semblent appartenir à génie logiciel.stackexchange.com o codereview.stackexchange.com
1 votes
Jetez un coup d'œil à semver.org (versionnement sémantique), cela devrait vous donner quelques idées.
1 votes
Mon expérience me dit d'utiliser un schéma légèrement différent. 1. sous-répertoire : a Git devrait au moins commencer par
v/car cela permet de regrouper les balises dans un espace de nom. 2. idéalement, une balise devrait également contenir un acronyme qui identifie de manière unique l'application. par ex.v/myapp/1.0. Cela facilite la fusion des dépôts git : dans le cas où les applications seraient fusionnées, les balises n'entreront pas en collision dans l'espace de noms des balises.0 votes
Il y a une autre raison subtile de préférer et de promouvoir le préfixe v dans les balises : cela oblige la version à être toujours reconnue comme une chaîne de caractères par les outils, les bibliothèques et les langages qui pourraient autrement traiter 1.10 comme un nombre à virgule flottante et considérer qu'il s'agit en réalité de 1.1, ce qui n'est pas du tout conforme à la version. À l'échelle, le préfixe v s'est avéré être un bon moyen d'éviter les dommages de type "mojibake". Les outils qui ont vraiment besoin de la vraie version peuvent facilement enlever le préfixe v.
0 votes
La réponse est bloquée. Mais aucune réponse n'a d'information importante : Vous devez éviter les caractères '~', '^', ':', '\', '?', '[', et '*', et les séquences ".." et "@{" qui ont une signification spéciale pour revparse. Il ne doit pas non plus contenir d'espaces blancs. Il s'agit d'une validation correcte du nom de la balise. Je ne suis pas sûr qu'il s'agisse d'une validation complète, mais... c'est au moins une information de base sur le sujet.