it-swarm.com.de

Wann sollte ein Commit nicht versioniert werden?

Kontext: Ich habe kürzlich von Semantic Versioning erfahren und versuche herauszufinden, wie ich es praktisch am besten für meine eigenen Projekte verwenden kann.

Wann sollte ein Commit nicht mit einer aktualisierten Version versehen werden, da Semver größere Änderungen, kleinere Änderungen und Patches für die Versionierung berücksichtigt? 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 beliebte 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).

31
VortixDev

SemVer betrifft die Versionierung Releases, nicht Commits. Wenn Ihr Versionskontrollmodell erfordert, dass jedes Commit zum Master eine Freigabe ist, muss jedes Commit entsprechend dem Grad der Änderung markiert werden.

Im Allgemeinen entwickeln Projekte jedoch ein größtenteils stabiles Produkt auf Master und kennzeichnen die Releases, die sie für unterstützenswert halten. Wenn sie dies tun, werden sie gemäß ihrem Versionsschema markiert, das nicht unbedingt SemVer sein muss.

71
Alex Reinking

Versionsnummern sind Releases zugeordnet. Im Allgemeinen sollte nicht jedes Commit eine Freigabe 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, aber in komplexer Software wird wahrscheinlich nicht jedes Problem erkannt. Einige Probleme können hardware- oder konfigurationsspezifisch sein, andere betreffen eher menschlich-subjektive Überlegungen als hart testbare Anforderungen.

Zweitens sollte es eine seltene Aktion sein, die Hauptversionsnummer zu erhöhen. Grundsätzlich bedeutet dies, 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 dann vollständige (nicht Alpha/Beta) Versionen hinzufügen sollten, wenn Sie bereit sind, diese Funktionen in ihrer jetzigen Form langfristig zu unterstützen.

Drittens ist es hilfreich, die Anzahl der weit verbreiteten Versionen gering zu halten. Selbst in einem stabilen Zweig ist es oft besser, mehrere Fixes zusammenzutragen und eine einzelne Version zu erstellen, als für jede Korrektur eine Version zu erstellen.

11
Peter Green

Scheint offensichtlich zu sagen, aber: Ein Zweck der Versionsnummern besteht darin, dass Sie leicht feststellen können, welche Version der Software von jemandem 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 dies als die 'erste Regel'. Infolgedessen möchten unterschiedliche Versionen eindeutig unterschiedliche Versionsnummern.

Es kommt jedoch 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 Funktion geändert hat.

Wie weit von "einer Version pro Vollversion" bis zu "einer Version für jedes Commit" entfernt ist, hängt wirklich davon ab: Sie, die anderen Benutzer, und welche Systeme Sie verwenden möchten, um die Lücken zu schließen.

Ich persönlich bin es gewohnt, an kleinen Projekten zu arbeiten, und verwende gerne Git-Hashes, bis eine Version, die andere verwenden, und eine Bump-Version für jede dieser Projekte (egal wie wenige Leute ich erwarte, sie in die Hände zu bekommen). In größeren Unternehmen und größeren Projekten wird jedoch etwas außerhalb der semantischen Versionsnummern verwendet, jedoch eine geringere Wiedergabetreue als bei jedem Commit, z. B. die Nummerierung von Release-Kandidaten. Diese haben Vorteile, erhöhen aber die Komplexität.

2
ANone

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

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

Abhängig vom Workflow Ihres Teams kann es jedoch immer noch zu mehreren Commits kommen, die ohne Version gemeistert werden müssen. Wenn eine Pull-Anfrage mehrere Commits enthält, die nicht gequetscht werden (meiner Meinung nach sollten sie nicht gequetscht werden), erhalten Sie möglicherweise immer noch 10 Commits und nur 1 neue Version.

0
xyious