Wann sollte ein Commit nicht mit einem Versions-Tag versehen werden?

Kontext: Ich habe kürzlich etwas über die semantische Versionierung erfahren und versuche herauszufinden , wie ich sie praktisch für meine eigenen Projekte verwenden kann.

In Anbetracht der Tatsache, dass Semver wichtige Änderungen, geringfügige Änderungen und Patches für die Versionierung berücksichtigt, sollte ein Commit nicht mit einer aktualisierten Version versehen werden? Es scheint mir, dass jede Änderung in eine dieser Kategorien passen würde und daher sollte jede Änderung versioniert werden, aber wenn ich mir verschiedene populäre Projekte auf GitHub anschaue, scheint dies nicht die Art und Weise zu sein, wie die Dinge gemacht werden (nur die Tatsache, dass große Projekte Zehntausende von Commits mit nur Hunderten von Tags haben).

SemVer betrifft Versionierung Versionen , nicht verpflichtet . Wenn Ihr Versionskontrollmodell zufällig erfordert, dass jedes Commit an Master ein Release ist, muss jedes Commit entsprechend dem Grad der Änderung markiert werden.

Im Allgemeinen entwickeln Projekte jedoch ein weitgehend stabiles Produkt auf master und markieren die Releases, die ihrer Meinung nach unterstützt werden sollten. Wenn sie dies tun, werden sie gemäß ihrem Versionsschema markiert, was nicht unbedingt SemVer sein muss.

Versionsnummern werden Releases zugeordnet. Im Allgemeinen sollte nicht jedes Commit ein Release sein. Dafür gibt es mehrere Gründe.

Erstens, während Sie sagen, dass Sie jedes Commit "testen", gibt es Teststufen. Das Ausführen einer automatisierten Testsuite auf einem Computer ist in Ordnung und gut, aber in komplexer Software wird wahrscheinlich nicht jedes Problem behoben. Einige Probleme können hardwarespezifisch oder konfigurationsspezifisch sein, andere betreffen eher subjektive Überlegungen als schwer überprüfbare Anforderungen.

Zweitens sollte das Erhöhen der Hauptversionsnummer eine seltene Aktion sein. Dies bedeutet im Grunde, dass alles, was von Ihrer Software abhängt, manuell überprüft werden muss, um festzustellen, ob es von einer der entfernten Funktionen abhängt.

Dies hat zur Folge, dass Sie Ihrer "öffentlichen API" nur Funktionen in vollständigen (nicht Alpha / Beta) Versionen hinzufügen sollten, wenn Sie bereit sind, diese Funktionen in ihrer gegenwärtigen Form langfristig zu unterstützen.

Drittens ist es hilfreich, die Anzahl der weit verbreiteten Versionen so gering wie möglich zu halten. Selbst auf einem stabilen Zweig ist es oft besser, mehrere Fixes zusammenzufassen und ein einzelnes Release zu erstellen, als für jedes Fix ein Release zu erstellen.

Es scheint naheliegend zu sein, aber: Mithilfe von Versionsnummern können Sie auf einfache Weise feststellen, welche Version der Software ausgeführt wird.

Wenn die Möglichkeit besteht, dass jemand Zugriff auf eine bestimmte Iteration des Codes hat und ansonsten nicht leicht in der Lage ist, eine eindeutige Kennung zu ermitteln, sollte diese Iteration eine eindeutige Versionsnummer haben. Ich sehe das als die 'erste Regel'. Infolgedessen benötigen unterschiedliche Releases eindeutig unterschiedliche Versionsnummern.

Es kommt jedoch noch mehr ins Spiel:

Eine Möglichkeit, dies sicherzustellen, besteht darin, die Versionsnummern bei jedem Commit zu erhöhen. Dies ist jedoch normalerweise keine gute Idee. Es kann mehrere Commits / Iterationen erfordern, bis eine relativ kleine Änderung funktioniert, und es ist für die Außenwelt verwirrend, Version 0.0.1 -> 0.0.2 als Ergebnis einer großen Anzahl akkumulierter Änderungen zu sehen, dann 0.0.2 -> 0.0 .56 weil jemand einen Leerraum festgeschrieben hat, der jeweils eine Datei repariert und nichts an der Funktionalität geändert hat.

Wie weit es von "einer Version pro Vollversion" bis zu "einer Version für jedes Commit" geht, hängt davon ab, ob Sie, die anderen Benutzer, und auf welchen Systemen Sie bereit sind, die Lücken zu schließen.

Ich persönlich bin es gewohnt, an kleinen Projekten zu arbeiten, und benutze GIT-Hashes gerne bis zu einer Version, die andere verwenden, und eine Bump-Version für jede dieser Versionen (unabhängig davon, wie wenig Leute ich damit rechne). In größeren Unternehmen und größeren Projekten wird jedoch etwas anderes als semantische Versionsnummern verwendet, jedoch eine geringere Wiedergabetreue als bei jedem Commit, beispielsweise die Nummerierung von Release-Kandidaten. Diese haben Vorteile, erhöhen jedoch die Komplexität.

Jede Pull-Anforderung, die zum Master zusammengeführt wird, sollte versioniert werden.

Wenn es sich nicht um eine neue Version (zumindest um einen Patch) handeln sollte, sollte sie wahrscheinlich nicht zum Master zusammengeführt werden, da das Feature / fix / etc nicht vollständig ist.

Abhängig vom Workflow Ihres Teams müssen Sie jedoch möglicherweise immer noch mehrere Commits ausführen, ohne eine Version zu haben. Wenn es mehrere Commits in einer Pull-Anfrage gibt, die nicht gequetscht werden (meiner Meinung nach sollten sie nicht gequetscht werden), haben Sie möglicherweise immer noch 10 Commits und nur eine neue Version.