Versionsformat einer Anwendung nach Jahren ändern?

[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