Versionsformat einer Anwendung nach Jahren ändern?

[SneakyBagels]

Ich entwickle schon seit längerer Zeit eine relativ aufwändiges Programm.
Meine Versionsnummer ist wie der Standard vorgibt: Major, Minor (immer 0), Ausgabe, Build.

Ich frage mich, ob es eine gute Idee ist die Versionierung noch im Nachhinein zu ändern.
Das folgende Format spricht mich sehr an und würde zeitgleich noch das Problem lösen, dass "Ausgabe" sonst in die Höhe schießt: Jahr, Monat, Tag.

Was denkt ihr? Machbar ist es, aber ist es gut?

[Der schöne Günther]

Beispiele für Software-Produkte die ihre Versionsnummern-Strategie irgendwann einmal änderte gibt es doch genug.

Ich verstehe nur nicht was du damit gewinnst die Nummern zwingend am Datum deiner Zeitzone festmachen zu wollen. Als Nutzer interessiert es mich doch in der Regel nicht wann du auf F9 gedrückt hast. Bei der klassisch aufsteigenden Nummerierung hingegen sehe ich direkt "höher ist neuer", beim Datum muss ich jedes mal alle drei Zahlenblöcke "parsen".

[himitsu]

Jahr.Monat.Tag.Patch

Wäre schon möglich.
Vorgegeben ist dabei nur, dass es alles jeweils nur 16-Bit-Werte sind.

So lange die neue Nummer größer ist, als die Alte, ist dch alles OK.
Problem ist nur, dass man nicht mehr den Unterschied zwischen großen "Änderungen" erkennt (neue Hauptversion, kleiner Änderungen/Bugfixes), aber da könnte man einfach bei großen Sprüngen den Patch auf 0 setzen und dann jeweils um 1 hochzählen.

Mindestens 2 Stellen mußt du auch so durchparsen. (Major.Minor.x.x)
Und das past bei dieser Nummerierung ebenfalls, da die Zeit absteigend ist.

Zum schnelleren Lesen könnte man das Jahr noch 2-stellig machen.
Bis zum nächsten Jahr-2000-Problem (19xx), ähhh Jahr 20100 (20xx), dauert es wieder ein paar Jahre.
Oder Jahr.TagImJahr.0.Patch , aber wer will da immer gern rechnen
und YY.MMDD.0.Patch macht dann auch keinen großen Unterschied, gegenüber YY.MM.DD.Patch

[freimatz]

Zitat:

Zitat von SneakyBagels (Beitrag 1374697)

Was denkt ihr? Machbar ist es, aber ist es gut?

Nein!
Propritäres ist immer schlecht.
Mach es wie hier: https://de.wikipedia.org/wiki/Versionsnummer
Siehe auch: https://www.heise.de/developer/artik...n-1859566.html

[SneakyBagels]

Naja wenn man danach geht habe ich eine komplett falsche Versionierung.

Ich habe 1.0.2.3
Die Nebenversionsnummer bleibt immer gleich, die Revisionsnummer ist mittlerweile zweistellig und die Buildnummer vierstellig.

Wäre es denn ratsam hier auf das im Wiki erwähnten Format zu wechseln?

[himitsu]

Zitat:

Zitat von freimatz (Beitrag 1375095)

Zitat:

Zitat von SneakyBagels (Beitrag 1374697)

Was denkt ihr? Machbar ist es, aber ist es gut?

Nein!
Propritäres ist immer schlecht.
Mach es wie hier: https://de.wikipedia.org/wiki/Versionsnummer

Zitat:

Eine klassische Versionsnummer

https://de.wikipedia.org/wiki/Versio...rketingaspekte
Marketingaspekte, der vorletzte Punkt

Also ist es ja nicht so ungewöhnliches.


Und wenn ich mich noch an die kranken Versionssprünge von Firefox/Thunderbird erinnere, wo ne ganze Zeit lang fast monatlich die Major-Version stieg, anstatt der Minor, da sich fast nie groß etwas änderte.

Eine Versionsnummer soll aufsteigend sein
und ob man nun immer +1 rechnet
oder einfach nur das Veröffentlichungsdatum nimmt
...
aufsteigend ist aufsteigend
und so hat man sogar gleich noch das Alter der Version direkt vor Augen. (auch wenn "alt" nicht immer schlecht bedeutet, so lange alles problemlos funktioniert)

[juergen]

Hallo,

ich persönlich halte den Aspekt von himitsu mit einer Hauptversion und Nebenversion schon für wichtig.
In dem 3. Part der Versionsnummer (Ausgabe) finde *ich* ein JJJJMMDD für sinnvoll und im 4. Part (Build) eine fortlaufende Nummer, wenn es mehrere Versionen von einem Tag gibt.

Grüße

[SneakyBagels]

Angenommen ich wechsle zu 2017-06-21.
Wäre in der IDE die Hauptversion dann 2017, die Ausgabe 06 und Build 21?

Zitat:

In dem 3. Part der Versionsnummer (Ausgabe) finde *ich* ein JJJJMMDD für sinnvoll und im 4. Part (Build) eine fortlaufende Nummer, wenn es mehrere Versionen von einem Tag gibt.

Wie genau meinst du das?
Heißt das Haupt- und Nebenversion bleiben leer?

[juergen]

Zitat:

Zitat von SneakyBagels (Beitrag 1375110)

Zitat:

In dem 3. Part der Versionsnummer (Ausgabe) finde *ich* ein JJJJMMDD für sinnvoll und im 4. Part (Build) eine fortlaufende Nummer, wenn es mehrere Versionen von einem Tag gibt.

Wie genau meinst du das?
Heißt das Haupt- und Nebenversion bleiben leer?

Nein, Haupt- und Nebenversion bleiben auf keinen Fall leer.
Beispiel:
Hauptversion=6
Nebeneversion=20
Ausgabe=2403 (Kalenderwoche + Wochentag-Nr., Mittwoch =03)
Build=1

[SneakyBagels]

Aber würde man hier dann nicht einen Mix aus zwei verschiedenen Dingen haben?

[juergen]

Zitat:

Zitat von SneakyBagels (Beitrag 1375113)

Aber würde man hier dann nicht einen Mix aus zwei verschiedenen Dingen haben?

Ja, genau das will ich ja. Ich will die Hauptversion sehen und das Erstelldatum.
Habe aber gerade gesehen, dass Ausgabe nur 4 Zahlen kann, Kalenderwoche und den Wochentag (heute wäre dann 2403) (Montag=01, Sonntag=07)

[SneakyBagels]

Nh das sieht für mich doch reichlich undurchsichtig für den Nutzer aus.

[bepe]

Zitat:

Zitat von SneakyBagels (Beitrag 1375117)

Nh das sieht für mich doch reichlich undurchsichtig für den Nutzer aus.

Soweit ich zurück denken kann entwickele ich Software. Ich bin also kein durchschnittlicher Nutzer. Aber höchstens bei der Hälfte der Software, welche ich einsetze, kann ich dir die Major Version nennen. Einem Nutzer ist die Nummer und vor allem wie diese Zustande kommt, wohl so ziemlich gleichgültig.

Mach was du für sinnvoll hältst bzw. dir hilft. Wichtig ist doch nur, dass die Nummer mit jeder Version steigt und größere Updates für den Anwender, anhand eines "großen Sprungs" erkennbar sind (du hast 4.1/Berlin möchtest du 4.2/Tokyo laden).

Ich habe noch nie gehört/erlebt, dass ein Anwender* die Build oder Release Nummer nennen konnten, ohne Schritt für Schritt zur Infobox gelotst zu werden.


* Große Kunden mit IT Personal oder entsprechend geschulten Ansprechpartner zählen hier nicht ;)

[Delphi-Laie]

Zitat:

Zitat von SneakyBagels (Beitrag 1374697)

Meine Versionsnummer ist wie der Standard vorgibt: Major, Minor (immer 0), Ausgabe, Build.

Ich frage mich, ob es eine gute Idee ist die Versionierung noch im Nachhinein zu ändern.
Das folgende Format spricht mich sehr an und würde zeitgleich noch das Problem lösen, dass "Ausgabe" sonst in die Höhe schießt: Jahr, Monat, Tag.

Was denkt ihr? Machbar ist es, aber ist es gut?

Es ist das einzig objektive Format.

Was eine Haupt-, eine Neben- und sonstwas für eine Nummer des Programmes ist, ist weitgehend willkürlich. Natürlich gibt es auch Gegenbeispiele. Zwischen Windows 3.x und 95/NT oder XP zu Vista ist der Sprung zu einer neuen Hauptversion(snummer) m.E. eindeutig.

Ein solches Datumsformat ist zudem auch absolut "zukunftssicher", sofern man nicht wieder davon abrückt.

Eine Minorversionsnummer, die zudem immer nur 0 ist, ist zudem pure Redundanz.

[Luckie]

Ich packe das Datum in die Infobox und aktualisiere es vor dem Release. ansonsten wie in dem Wikipedia Artikel.

[bra]

Die Version spielt heute doch oft gar keine Rolle mehr. Siehe diverse Browser. Wir setzen bei unserem Produkt auch bei jeder neuen Version nur noch die Hauptversion hoch und die Build-Nummer: 15.0.0.1234. Bei unserer App wird dagegen einfach fortlaufend gezählt: 1.6, 1.7 usw. nach 1.9 kommt vermutlich 2.0? ;D

[himitsu]

Die meisten User können mit den Zahlen ab der 2. Stelle eh nichts anfangen, vorallem die vorletzte Stelle versteht kein Schwein.

Zitat:

Zitat von bra (Beitrag 1375136)

Bei unserer App wird dagegen einfach fortlaufend gezählt: 1.6, 1.7 usw. nach 1.9 kommt vermutlich 2.0? ;D

Oder 1.10 ... blöd nur, dass bei der Zweieranzeige (Major.Minor) so mancher denkt das sei eine Dezimalzahl und bei der wäre 1.10 kleiner als 1.9 :stupid:

[Namenloser]

Zitat:

Zitat von bra (Beitrag 1375136)

Siehe diverse Browser.

Ich finde das ist ein gutes Anti-Beispiel. So sollte man es nicht machen. Ich sehne mich zurück zu den Zeiten, in denen die Firefox-Versionsnummer noch eine Bedeutung hatte und nicht nur "mehr = besser" "Chrome ist schon bei Version drölfhundertfünfzig, wir müssen aufholen, indem wir jede Woche eine neue 'Major'-Version raushauen". Scheiß Marketing.

[himitsu]

Problem ist ja hier nun, dass die nummern schon sooo groß sind und man nicht mehr zurück "kann", da die nummer dann ja kleiner wird.
Microsoft hätte von vorne beginnen können, da anderer/neuer Browser.

Bei deren Jagt hätte ein Datumsformat den Vorteil, dass automatisch alle fast die selbe Nummer (Datum) hätten.

[bra]

Zitat:

Zitat von Namenloser (Beitrag 1375141)

Zitat:

Zitat von bra (Beitrag 1375136)

Siehe diverse Browser.

Ich finde das ist ein gutes Anti-Beispiel. So sollte man es nicht machen. Ich sehne mich zurück zu den Zeiten, in denen die Firefox-Versionsnummer noch eine Bedeutung hatte und nicht nur "mehr = besser" "Chrome ist schon bei Version drölfhundertfünfzig, wir müssen aufholen, indem wir jede Woche eine neue 'Major'-Version raushauen". Scheiß Marketing.

So hab ich vor ein paar Jahren auch noch gedacht, als Mozilla damit angefangen habt. Inzwischen ist es aber wirklich so, dass mich die Browser-Version 0 interessiert und 95% der Anwender sicher auch. Automatische Updates und gut. Bei Apps aus den diversen Stores spielt die Version sowieso keine Rolle mehr.

[Rollo62]

Ich benutze auch gerne yymmdd für Versionen aller Art.

Getreu dem Motto: Der Timestamp ist die Beste Versionsnummer.

Es gibt aber auch tatsächlich Kunden die das nicht immer wollen, z.B. weil man dann das Produktionsdatum erraten kann
(wie ich habe eine Software von 2011, wann gibts mal ein Update) ?

Rollo

[SneakyBagels]

Zitat:

(wie ich habe eine Software von 2011, wann gibts mal ein Update) ?

Ich würde das yyymmdd-Format eher so anwenden, dass bei jedem Update das Datum angepasst wird.

[bra]

Aber wenn es kein Update gibt, sieht man das halt sofort ;)

[Benedikt Magnus]

Ich nutze seit jeher Major.Minor.Bugfix (wie bei Wikipedia, nur ohne Build) und bin damit immer gut gefahren. Die Angabe einer Buildnummer habe ich nie gebraucht. Wenn jede Version nur zu einem Build gehört, wie es sein sollte, dann wäre das einfach eine redundante Angabe.
Solange es für eine Minorversion keinen Bugfix gab, wird der auch ganz weggelassen, das hält die Versionsangaben schön klein und für Nutzer einfacher.
Das Datum zu verwenden widerstrebt mir gleich zweifach: Zum einen widerspricht es meinem logischen Drang, als Programmierer aufsteigende Zahlen zu verwenden (:stupid:), zum anderen erscheint es mir als Nutzer nicht ganz als Version und ich weiß nicht, was nun die nächste Version ist. Ubuntu bildet hier auch eine Ausnahme: Das Datum wird "versionsartig" verwendet und die Daten, an denen neue Versionen kommen, stehen klar fest: Jeden April und Oktober. Das macht es wieder übersichtlich (zumindest bis ins Jahr 2100).

[Uwe Raabe]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1375154)

Ich nutze seit jeher Major.Minor.Bugfix (wie bei Wikipedia, nur ohne Build) und bin damit immer gut gefahren. Die Angabe einer Buildnummer habe ich nie gebraucht. Wenn jede Version nur zu einem Build gehört, wie es sein sollte, dann wäre das einfach eine redundante Angabe.

Es gibt aber schon einen Anwendungsfall für die Buildnummer: während der Beta-Phase bleiben die ersten drei Versionsteile gleich, aber die Buildnummer wird mit jedem Beta-Release erhöht. So lassen sich die verschiedenen Bugtracker-Cases der Betatester besser zuordnen.

Früher hatten wir für die Buildnummer immer die Revisionsnummer des SVN genommen, aber seit Mercurial im Einsatz ist gibt es sowas ja nicht mehr. Jetzt wird die Buildnummer vom CI-System vergeben und als Tag ans VCS angehängt. Wichtig ist halt, daß man zu jedem Build die passenden Sourcen wiederfinden kann.

Ich habe auch einen Fall, wo ein Produkt unter zwei Namen vertrieben wird, die auch eine unterschiedliche Versionszählung haben. Die Buildnummer ist aber bei beiden gleich.

[Phoenix]

Im Bereich der Bibliotheken im Open-Source Sektor, insbesondere im JavaScript / Node und .NET Umfeld hat sich inzwischen das sogenannte Semantic Versioning durchgesetzt: http://semver.org/

Kurz: Major.Minor.Patch.

Optional gibts noch ein Suffix, das z.b. sonstige Metadaten wie Buildzeitpunkt mittracken kann und/oder Prerelease-Versionen (zb. beta-builds) deklariert.

Patch wird bei Bugfixes hochgedreht.
Minor wird bei neuen Features hochgedreht.
Major wird hochgedreht sobald es breaking changes gibt.

Prerelease-Informationen werden mit einem Minus angehaengt, Build-Metadaten mit einem plus, und sie duerfen auch mehrere Elemente behinhalten.
Beide sind rein ASCII alphanumerisch plus Bindestrich.

Beispiele:
1.0.0-beta.1 (ist die erste Beta)
1.0.0-beta-1 (ist die erste Beta, andere schreibweise)
3.2.17+20170623 (wurde am 23.06.2017 gebaut)
3.2.17+date.20170623 (wurde am 23.06.2017 gebaut, und ist etwas sprechender)
2.1.0-beta.2+branch.feature-brmpft.svnrev.57 (ist ein build zur beta 2 und wurde aus SVN revision 57 aus dem branch feature-brmpft gebaut)

Normalerweise sieht man nur normale und prerelease versionen. Metadaten sind eher selten und werden meist nur in internen builds zum testen verwendet.

[Headbucket]

Zitat:

Zitat von Uwe Raabe (Beitrag 1375158)

Zitat:

Zitat von Benedikt Magnus (Beitrag 1375154)

Ich nutze seit jeher Major.Minor.Bugfix (wie bei Wikipedia, nur ohne Build) und bin damit immer gut gefahren. Die Angabe einer Buildnummer habe ich nie gebraucht. Wenn jede Version nur zu einem Build gehört, wie es sein sollte, dann wäre das einfach eine redundante Angabe.

Es gibt aber schon einen Anwendungsfall für die Buildnummer: während der Beta-Phase bleiben die ersten drei Versionsteile gleich, aber die Buildnummer wird mit jedem Beta-Release erhöht. So lassen sich die verschiedenen Bugtracker-Cases der Betatester besser zuordnen.

Vor einem Jahr war die Buildnummer für mich auch unwichtig. Seit wir jedoch auf Git umgestiegen sind, hole ich mir die Versionsnummer aus dem Git-Repository. Die Buildnummer ist in meinem Fall dann die Anzahl der Commits seit der letzten gültigen Versionsnummer im Repository. Damit hat diese Nummer dann auch seinen Sinn bei mir gefunden :-) Somit ist dann auch relativ leicht eine Rückverfolgbarkeit möglich und man erkennt Betaversionen. Nichtsdestotrotz wird trotzdem noch der aktuell gültige SHA mit in der EXE gespeichert.

Grüße
Headbucket