Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Es sit aber extrem nervig, wenn die mitgelieferte Version Bugs hat und die nicht behoben werden. Es wird zudem bei den meisten Programmen zwischen Bugfixversionen und denen die neue Funktionen bringen unterschieden. man kann sich ja mal die Versionsstände von Debian 8 anschauen kurz bevor 9 erschien. Da ist schon sehr altes Zeug dabei.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Sicher hat das seine Vorteil aber auch sehr viele Nachteile. Letztlich musst du darauf vertrauen, dass der Maintainer alle kritischen Lücken akribisch nachpflegt und selbst, wenn er das täte, ist er immer noch davon abhängig, dass auch der Entwickler alle geschlossenen Lücken sauber dokumentiert. Gerade letzteres passiert aber nicht immer. Zum einen, weil vielleicht gar nicht direkt klar ist, dass der behobene Bug auch als Sicherheitslücke missbraucht werden kann (siehe Debian und die längst gefixte Imagemagick-Lücke) oder weil der Entwickler Angreifer nicht zusätzlich darauf Aufmerksam machen will oder was weiß ich. Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.