semantic versioning und GIT

[H. R. (hacker_r)]

Hi
weiss jemand wie semantic versioning mit diesem Problem umgeht:

Ich habe 3 Kunden.
Kunde 1: will ein patch und dessen Release basiernd auf basis von 
1.1.1.3
Kunde 2: will ein patch und dessen Release basiernd auf basis von 
1.1.2.3
Kunde 3: will ein patch und dessen Release basiernd auf basis von 
1.1.3.3

1.1.3.3 ist top of the tree in git.

Kunde 1 und 2 wollen nicht auf 1.1.3.3 sondern auf ihren Stand bleiben.
Kein Problem, ich mache jeweils einen neuen branch für Kunde 1 & 2. Aber 
welche Versionsnummern vergebe ich jetzt an Kunde 1 und 2?

Vermisst "Semantic Versioning" hier nicht ein Zusatzfeld für patch 
releases ?

thx

[Blume (Gast)]

Was spuckt google denn dazu aus?

[physiker (Gast)]

Gibt es "das" semantic versioning scheme? Z.B. https://semver.org/
sieht ein Schema
major.minor.patch
vor. Ihr habt ja schon eine extra Ebene eingezogen, also könnt ihr noch 
eine dazufügen, falls es für euch Sinn ergibt und die eingesetzten tools 
damit umgehen können. Ich denke kritisch kann es höchstens sein, wenn es 
kompatibel mit package managern sein muss.

[H. R. (hacker_r)]

Was ist im Sinne von https://semver.org/ hier zu tun?
wie geht man mit Versionsnummer basiernd auf alten releases vor wenn man 
sich an https://semver.org/ anlehnen will?

physiker schrieb:
> Gibt es "das" semantic versioning scheme? Z.B. https://semver.org/
> sieht ein Schema
> major.minor.patch
> vor. Ihr habt ja schon eine extra Ebene eingezogen, also könnt ihr noch
> eine dazufügen, falls es für euch Sinn ergibt und die eingesetzten tools
> damit umgehen können. Ich denke kritisch kann es höchstens sein, wenn es
> kompatibel mit package managern sein muss.

[Achim H. (anymouse)]

Bei uns gibt es manchmal eine fünfte Stelle -- ganz selten.
Andererseits ist unsere Major-Version in den höheren einstelligen 
Zahlen.

Vielleicht solltet Ihr einfach die ersten oder sogar die ersten beide 
Stellen streichen -- wenn es bereits derart krasse Unterschiede zwischen 
einer 1.1.2 und einer 1.1.3 gibt.

Oder die letzte Stelle gibt das Datum "20190719" an.

Oder Ihr trennt deutlicher zwischen "Basis/Feature Version" und "Patch 
Revision", d.h. ZWEI Versionsnummern.

[Blume (Gast)]

major.minor.patch<.build> !!


<.build> wird oft wegglassen


und bitte bitte nicht die Punkte als Dezimaltrenner sehen.


ich hab schon version gesehen die *1.01* anfangen

normal

1.0 ->  1.1 -> .. ->   1.9

dann
1.10 -> 1.99

dann
1.100 ...

bei jetbrain ist die major nummer dreistellig

Build #CL-192.5728.70, built on July 18, 2019

Die ersten beiden ziffern (19) stehen für das Jahr.
Die folgende Ziffer (2) für das Release innerhalb diese Jahres.