Block > Changelog
2 min (354 Wörter, 2125 Zeichen)
Die Versionsnummerierungen (z.B. v12.0.0) waren bisher ausgerichtet an grossen Design- und/oder Unterbau-umbauungen und haben zuletzt der Semantic Versioning (SemVer) entsprochen.
Allerdings (die Frage habe ich mir schon laenger gestellt): Ist das sinnvoll?
Koennte sich die Hauptversion nicht auch am Jahr (2024) oder an dem Alter der Website (seit diesem Jahr 18, happy birthday 🎉) ausrichten?
Anders gefragt: warum ueberhaupt eine Version? Eine Website ist ja sowieso immer im Wandel (mal mehr, mal weniger).
Bisher mochte ich es, bei groesseren Aenderungen einen Versionssprung zu machen (zugegeben waren die Versionen schon immer etwas random vergeben worden). Also bei ganz grossen Sachen die Majorversion anzupassen, bei neuen Beitraegen usw. die Minorversion und Patchlevel habe ich bisher nicht wirklich genutzt (nach SemVer), haette aber z.B. der Git Commit-Hash sein koennen.
Allerdings mochte ich es nicht, bei jedem Beitrag/Linkdump die Minorversion anzupassen bzw. einen Eintrag zu schreiben. Und der Patchlevel wurde glaube ich nie genutzt.
Daher entscheide ich mich jetzt, die Version unabhaengig von Beitraegen usw. anzupassen, denn diese haben ja ueblicherweise selbst schon ein Datum anbei.
Die Version soll anhand des Datums bestimmt werden, an dem ich eben die letzten Aenderungen zusammenfasse. Und zwar nach folgendem Schema:
- Jahr = Majorversion
- Monat = Minorversion
- Tag = Patchlevel
Update (2024-04-01): Das hat sogar einen Namen: CalVer
Ansonsten verlasse ich mich auf die 10 letzten Aenderungen auf der Changelog-Seite.
Wenn ich das Schema mal (ohne name) uebernehme, kommt bei mir fuer
die aktuelle Version das hier raus:
2024.02.25.71-3babd0d
Waere auf jeden Fall auch eine Idee, danke 😊
Auch eine Moeglichkeit waere z.B. das hier:
$ git describe --tags --long --match "v*"
v2024.02.25-4-gc580cbe
Update (2024-10-28): Weitere Gedanken zur Release-Versionierung von Software-Projekten
Update (2024-11-06): Und dann gibt es auch noch ZeroVer 😅
FWIW: Ich verwende (auf Arbeit) mittlerweile git tags + git describe + eine Packung Regex für die Versionsvergabe, was dann so aussieht:
vX.Y.Zvergebe ich selber pergit tag(erster Commit in einer neuen Version),Nwird berechnet als Anzahl der Commits seit dem letzten Versionstag,shorthashist der gekürzte Commit-Hash , undnameist optional im Tag enthalten (also entwederv1.2.3oderv1.2.3-foo).