Quand un commit ne doit-il pas être balisé?

30

Contexte: J'ai récemment découvert le versionnage sémantique et j'essaie de déterminer la meilleure façon de l'utiliser pratiquement pour mes propres projets.

Étant donné que semver prend en compte les changements majeurs, les changements mineurs et les correctifs pour le contrôle de version, quand un commit ne doit-il pas être balisé avec une version mise à jour? Il me semble que chaque changement s'inscrirait dans l'une de ces catégories, et donc chaque changement devrait être versionné, mais quand je regarde divers projets populaires sur GitHub, cela ne semble pas être la façon dont les choses sont faites (juste en regardant le fait que les grands projets ont des dizaines de milliers de commits, avec seulement des centaines de balises).

— VortixDev
source

23

Est -ce tout commettras à maîtriser une écurie, testé, qualité assurée libération dans votre projet?

— Alex Reinking

1

@AlexReinking Chaque commit est testé, mais j'essaie juste de m'habituer aux pratiques courantes avec mes projets personnels, donc c'est juste moi qui le travaille et en tant que tel il n'y a pas vraiment de système en place autre que "faire un changement, tester moi-même, engagez-le ".

— VortixDev

Notez également que les balises peuvent être modifiées ultérieurement. Le seul identifiant de validation solide est la clé de hachage de validation.

— Thorbjørn Ravn Andersen

9

chaque engagement à maîtriser ??? vous ne devriez jamais vous engager à maîtriser. Chaque fusion vers master sonne beaucoup mieux.

— xyious

2

Je pense que @xyious frappe le clou sur la tête. Chaque commit qui aboutit sur master doit être étiqueté avec une version car chaque commit sur master doit être une fusion de versions de develop .

— BJ Myers

71

SemVer préoccupations versioning de presse , n'engage . Si votre modèle de contrôle de version exige que chaque commit à master soit une version, alors oui, chaque commit devra être balisé en fonction du degré de changement.

En règle générale, cependant, les projets développent un produit généralement stable sur master et marquent les versions qu'ils jugent dignes de support. Quand ils le font, ils baliseront selon leur schéma de version, qui ne doit pas nécessairement être SemVer en particulier.

— Alex Reinking
source

5

SemVer n'a généralement de sens que pour les bibliothèques où l'utilisateur est d'autres bits de code et non des humains. Il n'y a pas vraiment de changements "de rupture" dans la plupart des applications destinées aux utilisateurs, car l'utilisateur peut s'adapter automatiquement à la nouvelle version.

— Qwertie

5

Je dirais que les versions en ligne de commande des applications utilisateur doivent être versionnées sémantiquement car leurs indicateurs et formats de sortie peuvent se comporter différemment. Un peu de zone grise.

— Alex Reinking

5

@Qwertie Les attentes des utilisateurs sont moins rigides que les attentes des logiciels mais elles existent toujours. J'AI DÉFINITIVEMENT utilisé de nombreux logiciels qui ont émis ce que j'appellerais des changements de rupture à leur interface ou fonctionnalité. Décider ce qui constitue une version majeure ou mineure est certainement plus subjectif qu'avec les bibliothèques, mais ce n'est pas nécessairement une raison pour l'éviter.

— Iron Gremlin

11

@Qwertie - retarder la mise à niveau. Combien de personnes exécutent toujours d'anciennes versions majeures de Windows et Office?

— Alex Reinking

5

@Qwertie Ils pourraient être inspirés de lire attentivement le journal des modifications ou la documentation afin qu'ils puissent adapter la façon dont ils utilisent le système pour utiliser des fonctionnalités nouvelles ou modifiées, ou trouver des solutions de contournement pour une fonctionnalité qui a été supprimée. C'est le même cas, leur utilisation du logiciel doit changer parce que le logiciel a changé, vous devez donc leur parler de ce changement sans ambiguïté.

— Iron Gremlin

11

Les numéros de version sont attribués aux versions. En général, tous les commit ne doivent pas être une version. Il y a plusieurs raisons à cela.

Premièrement, pendant que vous dites que vous "testez" chaque commit, il existe des niveaux de test. Exécuter une suite de tests automatisée sur une seule machine est bien beau, mais dans un logiciel complexe, il ne détectera probablement pas tous les problèmes. Certains problèmes peuvent être spécifiques au matériel ou à la configuration, certains problèmes peuvent être davantage liés à des considérations subjectives humaines qu'à des exigences éprouvables.

Deuxièmement, le remplacement du numéro de version principal devrait être une action rare. Cela signifie essentiellement que tout ce qui dépend de votre logiciel doit être vérifié manuellement pour voir s'il dépend de l'une des fonctionnalités supprimées.

Une conséquence de cela est que vous ne devez ajouter des fonctionnalités à votre "API publique" dans leurs versions complètes (et non alpha / bêta) que si vous êtes prêt à prendre en charge ces fonctionnalités sous leur forme actuelle à long terme.

Troisièmement, il est utile de limiter le nombre de versions largement utilisées. Même sur une branche stable, il est souvent préférable de rassembler un certain nombre de correctifs ensemble et de faire une seule version que de faire une version pour chaque correctif.

— Peter Green
source

2

Cela semble évident à dire, mais: le but des numéros de version est de vous permettre de déterminer facilement la version du logiciel que n'importe qui exécute.

S'il y a une chance que quelqu'un ait accès à une itération particulière du code et ne soit pas autrement en mesure de déterminer facilement un identifiant unique, alors cette itération devrait avoir un numéro de version unique. Je vois cela comme la «première règle». Par conséquent, les versions distinctes auront clairement besoin de numéros de version distincts.

Cependant, d'autres éléments entrent en jeu:

Une façon de s'en assurer consiste à augmenter les numéros de version avec chaque commit, mais ce n'est généralement pas une bonne idée. Cela peut prendre plusieurs validations / itérations pour obtenir un changement relativement petit, et il est déroutant pour le monde extérieur de voir la version 0.0.1 -> 0.0.2 à la suite d'un grand nombre de changements accumulés, puis 0.0.2 -> 0.0 .56 car quelqu'un qui a commis un espace blanc corrige un fichier à la fois et n'a rien changé de fonctionnel.

La distance entre "une version par version complète" et "une version pour chaque commit" dépend vraiment de vous, des autres utilisateurs et des systèmes que vous êtes prêt à utiliser pour combler les lacunes.

Personnellement, je suis habitué à travailler sur de petits projets, et je suis heureux d'utiliser des hachages git jusqu'à une version que d'autres utilisent et une version bump pour chacun d'entre eux (peu importe le nombre de personnes que je m'attends à mettre la main dessus). Cependant, dans les grandes entreprises et les projets plus importants, il existe quelque chose en dehors des numéros de version sémantiques, mais une fidélité inférieure à chaque commit, comme la numérotation des candidats aux versions, est utilisée. Ceux-ci ont des avantages mais ajoutent de la complexité.

— AUCUN
source

0

Chaque demande d'extraction qui est fusionnée au maître doit être versionnée.

S'il ne doit pas s'agir d'une nouvelle version (au moins un correctif), il ne devrait probablement pas être fusionné avec master car la fonctionnalité / correction / etc n'est pas complète.

Cependant, selon le flux de travail de votre équipe, vous pouvez toujours vous retrouver avec plusieurs validations à maîtriser sans version. S'il y a plusieurs commits dans une pull request qui ne sont pas écrasés (ils ne devraient pas à mon avis), vous pouvez toujours vous retrouver avec 10 commits et juste 1 nouvelle version.

— xyious
source