Grüß euch Ich hab eine Frage bezüglich "best practices" wenn es um Git Tags und Hardware Revisionen bzw. Produkttypen geht. Nehmen wir mal an es gibt den Release einer Software in V1.2 die bisher die beiden Produkte A und B unterstützt. Weil die Entwickler versuchen irgendwie ihren Verstand zu wahren nutzen sie Git Tags um die Releases zu kennzeichnen. Der entsprechende Commit wurde mit "v1.2" getagged. Nun wird der Code um einen weiteren Produkttypen C ergänzt. An der eigentlichen Applikationslogik ändert sich kein Strich, es kommt aber ein neuer Header hinzu der die entsprechende Konfiguration enthält (z.B. andere Pins oder wwi). Für den neuen Typen muss natürlich eine Software released werden. Die Frage ist, erhöht ihr die Versionsnummer in so einem Fall, oder behaltet ihr sie bei und ändert den bereits gesetzten Tag auf einen neuen Commit der die neue Konfiguration enthält? tia
Auch wenn ich nicht mit hardware-Versionen arbeite: In so einem Fall würde ich einen neuen Tag / eine neue Version anlegen. Allerdings vielleicht eher "1.2.1" oder gar "1.2.0.1" anstelle einer "1.3". Dann weiß man auch: C wird erst mit 1.2.1 unterstützt; wenn es mit C einen Fehler gibt, und die Software ist erst 1.2, kann man besser die möglichen Fehlerursachen trennen.
Eine "Patch" Version ist aus historischen Gründen in dem Fall leider keine Option. Das heißt dein Vorschlag wäre dann quasi eine 1.3?
Vincent H. schrieb: > Eine "Patch" Version ist aus historischen Gründen in dem Fall leider > keine Option. Dann würde ich erhöhen. Die Funktionalität hat ja zugenommen (Es funktioniert mit einer neuen HW). Es gibt ja wohl hoffentlich eine Änderungshistorie, wo man die Unterschiede reinschreibt.
Gast
#6614726
Ganz einfach: Einen einmal veröffentlichten Tag (also gepusht), lässt man auf alle Ewigkeiten. Alles andere gibt kudelmudel. Aber: Git ist kein Tool für Varianten-Management. Git ist für Quellcode-Versionierung. Das sind zwei völlig verschiedene Probleme.
Gast
#6614764
Experte schrieb: > Ganz einfach: Einen einmal veröffentlichten Tag (also gepusht), lässt > man auf alle Ewigkeiten. > > Alles andere gibt kudelmudel. Dem Schließe ich mich an, ein Tag wird nicht mehr verändert, die Version ist verbrannt. Wenn was neues Hinzukommt brauchst du einen neuen Tag! Denn selbst wenn die Änderung trivial sein sollte, kann sie dennoch einen Seiteneffekt haben, auch wenn der Entwickler schwört, dass es nicht der Fall sein wird. Man mal kann es sogar sinnvoll sein den Tag zu signieren, um sicherzustellen, das dieser nicht verändert worden ist.
Danke für den Input.
Gast
#6625188
Imonbln schrieb: > Dem Schließe ich mich an, ein Tag wird nicht mehr verändert, die Version > ist verbrannt. Wenn was neues Hinzukommt brauchst du einen neuen Tag! > > Denn selbst wenn die Änderung trivial sein sollte, kann sie dennoch > einen Seiteneffekt haben, auch wenn der Entwickler schwört, dass es > nicht der Fall sein wird. Richtig. Was einmal einen Namen bekommen hat bleibt auch für immer so. Auch wenn es kaputt ist, oder unvollständig. Dann ist halt z.B. v1.2.3 kaputt. Dann ist das eben so. Das vermerkt man in den Notes zu dieser Version und gut. Habe selbst schon so Dinge erlebt, wie: v1.8 war noch frei. Ich hab da mal als v1.8 getagt, wobei die SW schon bei Stand 2.1 war... Mit diesen zwei Regeln fahre ich sehr gut: 1) Getagte Stände werden nicht angefasst. Unter keinen Umständen. 2) Die Versionsnummer ist streng monoton steigend und zählt nicht auch mal rückwärts. Mit folgendem Versionierungschema, fahren wir ganz gut: vX.Y(.Z) X für Major-Releases, bei denen sich API- oder andere massive Änderungen ergeben. Y Für Feature-Änderungen/Erweiterungen, die rückwärtskompatibel sind bzw. nur ergänzend. Je nach Software und $Gründen kann auch noch eine dritte Zahl verwendet werden. Kommt darauf an, wie feinstufig man die SW entwickelt. Zusätzlich verwenden wir noch mit Bindestrichen Patchevels. Ist in v1.2.3 ein Fehler, und kann au einem Grund keine neuere Softwareversion verwendet werden, dann wird eine Version v1.2.3-1 mit dem Bugfix erstellt.
Gast
#6625206
Semantic Versioning folgen, dementsprechend: - Major Releases => Breaking Changes - Minor Releases => Features (auch neue Hardware supported) - Patch Releases => Bugfixes aber auch: einmal gemachte Versionen werden NIE wieder angefasst. Ergo würde ich hier auch eine 1.3 bauen.
M. H. schrieb: > Mit diesen zwei Regeln fahre ich sehr gut: > 1) Getagte Stände werden nicht angefasst. Unter keinen Umständen. > 2) Die Versionsnummer ist streng monoton steigend und zählt nicht auch > mal rückwärts. Diese beiden Regeln halte ich für essenziell. Martin schrieb: > Semantic Versioning folgen, dementsprechend: > - Major Releases => Breaking Changes > - Minor Releases => Features (auch neue Hardware supported) > - Patch Releases => Bugfixes > > aber auch: einmal gemachte Versionen werden NIE wieder angefasst. > Ergo würde ich hier auch eine 1.3 bauen. Genau so.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.