daher mit jahreszahlen arbeiten

[traxanos]

daher finde ich es besser wie das einige distries auch machen jahreszahlen zu verwenden.

[superdachs]

traxanos schrieb:
--------------------------------------------------------------------------------
> daher finde ich es besser wie das einige distries auch machen jahreszahlen
> zu verwenden.

Oder einfach nur durch zu nummerieren. Warum muss man so etwas immer eine komplizierte interpretation aufdrücken?

[Sladen]

Eine Jahreszahl würde ich auch begrüßen für den Initial Release und bei Hotfixes in der Unterversion das Jahr.
Dann kann man immer gleich sehen wie hard geschlampft wurde bei der Pflege :D

[rawcode]

superdachs schrieb:
--------------------------------------------------------------------------------
> traxanos schrieb:
> ---------------------------------------------------------------------------
> -----
> > daher finde ich es besser wie das einige distries auch machen
> jahreszahlen
> > zu verwenden.
>
> Oder einfach nur durch zu nummerieren. Warum muss man so etwas immer eine
> komplizierte interpretation aufdrücken?

Naja, ich finde, das SemVer-System "A.B.C" hat schon seine Berechtigung. Patches? C erhöhen. Neue Ausstattung? B erhöhen. Alte Dinge über Bord geworfen bzw. wesentliche Dinge nicht-abwärtskompatibel geändert? A erhöhen. Da weiß man was man hat bzw. was einen erwartet, wenn man das Ding aktualisiert.

Klar, bei einem kompletten Betriebssystem, das man im Grunde immer als Major Release bezeichnen kann, gehen auch Jahreszahlen oder aufsteigende Nummern. Aber bei Bausteinen dieses Systems (Bibilotheken, Kernel, Tools) finde ich SemVer aussagekräftiger.

Hm..ist das jetzt Windows 11 oder Windows 3.1.27496? :)

Übrigens: "ein" wird mit 'n abgekürzt. Warum manche versuchen, das mit 'nen "abzukürzen" ist mir ein Rätsel.

[superdachs]

rawcode schrieb:
--------------------------------------------------------------------------------
> superdachs schrieb:
> ---------------------------------------------------------------------------
> -----
> > traxanos schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > daher finde ich es besser wie das einige distries auch machen
> > jahreszahlen
> > > zu verwenden.
> >
> > Oder einfach nur durch zu nummerieren. Warum muss man so etwas immer
> eine
> > komplizierte interpretation aufdrücken?
>
> Naja, ich finde, das SemVer-System "A.B.C" hat schon seine Berechtigung.
> Patches? C erhöhen. Neue Ausstattung? B erhöhen. Alte Dinge über Bord
> geworfen bzw. wesentliche Dinge nicht-abwärtskompatibel geändert? A
> erhöhen. Da weiß man was man hat bzw. was einen erwartet, wenn man das Ding
> aktualisiert.
>
> Klar, bei einem kompletten Betriebssystem, das man im Grunde immer als
> Major Release bezeichnen kann, gehen auch Jahreszahlen oder aufsteigende
> Nummern. Aber bei Bausteinen dieses Systems (Bibilotheken, Kernel, Tools)
> finde ich SemVer aussagekräftiger.
>
> Hm..ist das jetzt Windows 11 oder Windows 3.1.27496? :)

Das ist eben die völlig überholte Sichtweise der 80er und 90er. Heute wird anders entwickelt. Es ist völlig irrelevant ob nun etwas nur gefixt wurde oder eine neue Funktionalität implementiert wurde. Zumal reine Fixreleases in Zeiten agiler Entwicklung eher die Ausnahme darstellen. Was in einer Version enthalten ist sieht man ja an den Quellen. Das steht in den Commits und idealerweise noch in irgendwelchen Releasenotes. Regelmäßiges releasen ist dabei natürlich wichtig dann bleibts auch überschaubar. Eigentlich sollte nach jedem kontrollierten merge in den Hauptzweig ein Release erfolgen (können).

[bernd71]

superdachs schrieb:
--------------------------------------------------------------------------------
> rawcode schrieb:
> ---------------------------------------------------------------------------
> -----
> > superdachs schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > traxanos schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > daher finde ich es besser wie das einige distries auch machen
> > > jahreszahlen
> > > > zu verwenden.
> > >
> > > Oder einfach nur durch zu nummerieren. Warum muss man so etwas immer
> > eine
> > > komplizierte interpretation aufdrücken?
> >
> > Naja, ich finde, das SemVer-System "A.B.C" hat schon seine Berechtigung.
> > Patches? C erhöhen. Neue Ausstattung? B erhöhen. Alte Dinge über Bord
> > geworfen bzw. wesentliche Dinge nicht-abwärtskompatibel geändert? A
> > erhöhen. Da weiß man was man hat bzw. was einen erwartet, wenn man das
> Ding
> > aktualisiert.
> >
> > Klar, bei einem kompletten Betriebssystem, das man im Grunde immer als
> > Major Release bezeichnen kann, gehen auch Jahreszahlen oder aufsteigende
> > Nummern. Aber bei Bausteinen dieses Systems (Bibilotheken, Kernel,
> Tools)
> > finde ich SemVer aussagekräftiger.
> >
> > Hm..ist das jetzt Windows 11 oder Windows 3.1.27496? :)
>
> Das ist eben die völlig überholte Sichtweise der 80er und 90er. Heute wird
> anders entwickelt. Es ist völlig irrelevant ob nun etwas nur gefixt wurde
> oder eine neue Funktionalität implementiert wurde. Zumal reine Fixreleases
> in Zeiten agiler Entwicklung eher die Ausnahme darstellen. Was in einer
> Version enthalten ist sieht man ja an den Quellen. Das steht in den Commits
> und idealerweise noch in irgendwelchen Releasenotes. Regelmäßiges releasen
> ist dabei natürlich wichtig dann bleibts auch überschaubar. Eigentlich
> sollte nach jedem kontrollierten merge in den Hauptzweig ein Release
> erfolgen (können).

Macht sich besonders gut bei dynamischen Bibliotheken.

[1ras]

superdachs schrieb:
--------------------------------------------------------------------------------
> Das ist eben die völlig überholte Sichtweise der 80er und 90er. Heute wird
> anders entwickelt. Es ist völlig irrelevant ob nun etwas nur gefixt wurde
> oder eine neue Funktionalität implementiert wurde. Zumal reine Fixreleases
> in Zeiten agiler Entwicklung eher die Ausnahme darstellen. Was in einer
> Version enthalten ist sieht man ja an den Quellen. Das steht in den Commits
> und idealerweise noch in irgendwelchen Releasenotes. Regelmäßiges releasen
> ist dabei natürlich wichtig dann bleibts auch überschaubar. Eigentlich
> sollte nach jedem kontrollierten merge in den Hauptzweig ein Release
> erfolgen (können).

Man kann sich aber auch alles schönreden. Einen Fehler zu beheben und gleichzeitig an anderer Stelle 5 neue hinzuzufügen ist alles andere als irrelevant.

[pythoneer]

superdachs schrieb:
--------------------------------------------------------------------------------

> Das ist eben die völlig überholte Sichtweise der 80er und 90er. Heute wird
> anders entwickelt.

Also wenn man nicht gerade Go Entwicklung der ersten Stunde gemacht hat, dann würde ich das mal ganz stark anzweifeln. Mir tuen die Leute leid die ernsthaft "anders entwickeln" und sich täglich mit breaking changes der eigenen Libs herum ärgern müssen. Also das einzige was mir da einfällt ist alle Libs zu verndorn und niemals zu updaten und mit den Sicherheitslöchern leben. Wenn ich so darüber nachdenke, dann ist das in der Tat so wie scheinbar an vielen Stellen entwickelt wird – LEIDER.

So lässt sich sicher auch erklären warum Software immer schlimmer wird, wenn es nicht mehr geschafft wird wenigstens den Standard der 80er und 90er zu halten. Herr Blow hat darüber einen schönen Vortrag gehalten und zeigt ganz gut wie sich Software immer weiter verschlechtert.

https://www.youtube.com/watch?v=ZSRHeXYDLko

[treba]

rawcode schrieb:
--------------------------------------------------------------------------------
> ... Alte Dinge über Bord geworfen bzw. wesentliche Dinge nicht-abwärtskompatibel geändert? A erhöhen.

Im Fall von Linux ist das wenn ich mich nicht irre seit dem Sprung von 2.4 zu 2.6 nicht mehr passiert (und auch nicht für die Zukunft geplant). Daher ergibt das System hier nicht so viel Sinn.

[elf]

treba schrieb:
--------------------------------------------------------------------------------
> rawcode schrieb:
> ---------------------------------------------------------------------------
> -----
> > ... Alte Dinge über Bord geworfen bzw. wesentliche Dinge
> nicht-abwärtskompatibel geändert? A erhöhen.
>
> Im Fall von Linux ist das wenn ich mich nicht irre seit dem Sprung von 2.4
> zu 2.6 nicht mehr passiert (und auch nicht für die Zukunft geplant). Daher
> ergibt das System hier nicht so viel Sinn.

Wie meinst du das? ISDN ist später rausgeflogen. Und demnächst folgt DECNet. Das sind zumindest zwei wesentliche Dinge, mit denen ich hantier(t)e. Die sind einfach nicht mehr im Kernel.

[1ras]

elf schrieb:
--------------------------------------------------------------------------------
> treba schrieb:
> ---------------------------------------------------------------------------
> -----
> > rawcode schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > ... Alte Dinge über Bord geworfen bzw. wesentliche Dinge
> > nicht-abwärtskompatibel geändert? A erhöhen.
> >
> > Im Fall von Linux ist das wenn ich mich nicht irre seit dem Sprung von
> 2.4
> > zu 2.6 nicht mehr passiert (und auch nicht für die Zukunft geplant).
> Daher
> > ergibt das System hier nicht so viel Sinn.
>
> Wie meinst du das? ISDN ist später rausgeflogen. Und demnächst folgt
> DECNet. Das sind zumindest zwei wesentliche Dinge, mit denen ich
> hantier(t)e. Die sind einfach nicht mehr im Kernel.

IPX würde mir dazu auch noch einfallen und zu ISDN natürlich CAPI. In der Tat werden immer mal wieder Dinge aus dem Linux Kernel entfernt. Aber SemVer (https://semver.org/) wird vom Linux Kernel eh nicht genutzt.