Git Tags, Versionen und Produkttypen - best practice

[Vincent H. (vinci)]

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

[Achim H. (anymouse)]

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.

[Vincent H. (vinci)]

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?

[Andreas B. (bitverdreher)]

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.

[Experte (Gast)]

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.

[Imonbln (Gast)]

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.

[Vincent H. (vinci)]

Danke für den Input.

[M. Н. (Gast)]

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.

[Martin (Gast)]

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.

[Rolf M. (rmagnus)]

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.