Angstroem schrieb am 23. Juli 2014 21:54
> > Und selbst wenn schon... die Versionsnummer ist doch bedeutungslos.
>
> Nein, eben nicht. Ist das denn so schwer zu verstehen?
Hängt vom Context ab. Sowas wie "2.1" ist eine Marketing-Nummer, die
für die Technik völlig irrelevant ist.
Unsere Leute verkaufen sowas wie "4.0 RC2b" oder so (wobei ich noch
nicht ganz raushabe was die mit "RC" eigentlich meinen).
Intern könnte das "p123:f456:i78" heissen, was die Revisionsnummern
der drei beteiligten Repositories widerspiegelt. Mein Chef läßt
überall YYMMDD.HHMMSS "Build-IDs" anzeigen die für mich aber völlig
irrelevant und nutzlos sind -- aber mei, er ist der Chef. Der eine
oder andere weiß aber inzwischen wie man an die richtigen Build-IDs
rankommt :-)
Bei mir zuhause bestimmt das Build-Tool unter Linux und MacOS die
Versionsnummern von clang++ bzw. g++ (je nachdem was verwendet wird).
Die Version von VisualC++ wird derzeit als fix behandelt; wenn ich
z.B. auf 2013 umstelle verschwindet der Support für 2012 sowieso
komplett weil andere Registry-Keys verwendet werden und ich mir nicht
die Mühe mache festzustellen was eigentlich vorhanden ist und das
Zeug entsprechend anpasse. Bei g++ und clang++ ändert sich an den
Äußerlichkeiten wenig bzw. es ist mehr hardcodiert -- clang++ wird
halt immer als /usr/bin/clang++ aufgerufen; da funktionieren alte
Compiler halt wegen fehlender Features irgendwann nicht mehr.
CSBuilder führt inzwischen aber keinen Build mehr durch wenn der
Compiler nicht eine bestimmte Minimalversion hat.
Da interessiert mich aber auch nicht was das KONKRET für Zahlen sind;
verwendet wird das weil sich alle naselang die Kommandozeilenoptionen
ändern und es z.B. bei den Warning-Optionen halt eine Tabelle gibt wo
die Optionen mit Min/Max-Version Angaben ausgestattet sind. Insofern
müssen die Nummern lediglich eine vergleichbare Reihenfolge einhalten
-- ob ein Compiler nun "4.10", "5.0" oder "27.42" heisst ist mir aber
wurscht, vorausgesetzt daß 27.42 immer noch "neuer als 4.9" ist weil
der Vergleich das halt nahelegt und von CSBuilder so bahandelt wird.
Für eine "Build-Version" gibt es noch keinen konkreten Support; der
Plan ist ähnlich wie in der Firma die Revionsnummern und Branches der
beteiligten Repositories zu sammeln, diese aber (da es viel mehr
Daten sind) mit einer DB oder vermutlich einem weiteren Repository in
eine einzelne Revisionsnummer zu "kollabieren", so daß die Software
dann sowas wie "V2.0 Build 75" anzeigt, dieses "75" aber intern in
eine ganze Liste von Repository-Revisionen und -Branches expandiert
wird bevor es irgendwie nützlich ist.
Wie man sieht, der "technische" Aspekt einer Versionsnummer ist
wesentlich interessanter als das was eine Marketingabteilung als
Label sehen will. Gleichzeitig ist es für diese "technische Version"
völlig irrelevant was die Nummern bedeuten -- sie basieren oft
(immer?) auf reinen Revisionszählern und nie (fast nie?) auf
irgendwelchen manuellen Zuweisungen.
Christian
> > Und selbst wenn schon... die Versionsnummer ist doch bedeutungslos.
>
> Nein, eben nicht. Ist das denn so schwer zu verstehen?
Hängt vom Context ab. Sowas wie "2.1" ist eine Marketing-Nummer, die
für die Technik völlig irrelevant ist.
Unsere Leute verkaufen sowas wie "4.0 RC2b" oder so (wobei ich noch
nicht ganz raushabe was die mit "RC" eigentlich meinen).
Intern könnte das "p123:f456:i78" heissen, was die Revisionsnummern
der drei beteiligten Repositories widerspiegelt. Mein Chef läßt
überall YYMMDD.HHMMSS "Build-IDs" anzeigen die für mich aber völlig
irrelevant und nutzlos sind -- aber mei, er ist der Chef. Der eine
oder andere weiß aber inzwischen wie man an die richtigen Build-IDs
rankommt :-)
Bei mir zuhause bestimmt das Build-Tool unter Linux und MacOS die
Versionsnummern von clang++ bzw. g++ (je nachdem was verwendet wird).
Die Version von VisualC++ wird derzeit als fix behandelt; wenn ich
z.B. auf 2013 umstelle verschwindet der Support für 2012 sowieso
komplett weil andere Registry-Keys verwendet werden und ich mir nicht
die Mühe mache festzustellen was eigentlich vorhanden ist und das
Zeug entsprechend anpasse. Bei g++ und clang++ ändert sich an den
Äußerlichkeiten wenig bzw. es ist mehr hardcodiert -- clang++ wird
halt immer als /usr/bin/clang++ aufgerufen; da funktionieren alte
Compiler halt wegen fehlender Features irgendwann nicht mehr.
CSBuilder führt inzwischen aber keinen Build mehr durch wenn der
Compiler nicht eine bestimmte Minimalversion hat.
Da interessiert mich aber auch nicht was das KONKRET für Zahlen sind;
verwendet wird das weil sich alle naselang die Kommandozeilenoptionen
ändern und es z.B. bei den Warning-Optionen halt eine Tabelle gibt wo
die Optionen mit Min/Max-Version Angaben ausgestattet sind. Insofern
müssen die Nummern lediglich eine vergleichbare Reihenfolge einhalten
-- ob ein Compiler nun "4.10", "5.0" oder "27.42" heisst ist mir aber
wurscht, vorausgesetzt daß 27.42 immer noch "neuer als 4.9" ist weil
der Vergleich das halt nahelegt und von CSBuilder so bahandelt wird.
Für eine "Build-Version" gibt es noch keinen konkreten Support; der
Plan ist ähnlich wie in der Firma die Revionsnummern und Branches der
beteiligten Repositories zu sammeln, diese aber (da es viel mehr
Daten sind) mit einer DB oder vermutlich einem weiteren Repository in
eine einzelne Revisionsnummer zu "kollabieren", so daß die Software
dann sowas wie "V2.0 Build 75" anzeigt, dieses "75" aber intern in
eine ganze Liste von Repository-Revisionen und -Branches expandiert
wird bevor es irgendwie nützlich ist.
Wie man sieht, der "technische" Aspekt einer Versionsnummer ist
wesentlich interessanter als das was eine Marketingabteilung als
Label sehen will. Gleichzeitig ist es für diese "technische Version"
völlig irrelevant was die Nummern bedeuten -- sie basieren oft
(immer?) auf reinen Revisionszählern und nie (fast nie?) auf
irgendwelchen manuellen Zuweisungen.
Christian