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

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).

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.

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.

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é.

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.