auf KDE passt eine solche Vorgehensweise schlecht, schon alleine, weil es bei KDE immer bekannte Fehler gibt, die auch im nächsten Release nicht behoben werden.
Das System ist zu komplex, um fehlerfrei zu sein, bisweilen sind die Ansätze nur Versuche, die auf krude Weise funktionieren.
Bei KDE und Gnome gibt es darum einen eher zeitgesteuerten Verlauf von Releases. Darin wird nur geregelt, bis wann was gemacht werden kann und darf, und was wann nicht mehr.
Das ist darum nötig, weil KDE-Entwicklung nicht alleine von Entwicklern getrieben wird. Es gibt noch Übersetzer, Künstler, Dokumentierer, Tester, Experten für UIs, etc. die in einer Entwicklung nicht mitmachen können, sondern die Releases brauchen.
Wenn KDE 4.0 nicht pünktlich fertig wird, heisst das, diese ganze Gruppen nicht konstruktiv an KDE teilnehmen können. Die Leiter von KDE wollen weder die Entwickler zu lange auf Feedback warten lassen, noch die anderen aussen vorlassen.
Realistisch war es immer so, dass die Versionen 2.0.0 und 3.0.0 unbenutzbar waren, im Vergleich zu den Endpunkten der Vorgänger-Serien. Aber auch notwendige Zwischenschritte für ein solches Projekt. Solche Releases sind Pilotversionen, die mehr Potential, aber weniger Qualität haben, als die Vorgängerlinie.
Nach dem traditionellen Schema dürfte KDE noch nicht mal Beta releasen, weil Plasma noch nicht fertig ist (damit wurde erst spät begonnen).
Übrigends hat der Linux-Kernel das alte Release-Schema völlig aufgegeben, weil es einfach nicht funktioniert, lange Entwicklungszyklen mit fehlerfreien Versionen abzuschliessen.
Bei Linux hatte man da aber auch schon den Luxus, das Design richtig zu haben. Bei KDE könnte es passieren, dass es keine 5.0 mehr gibt, sondern auch nur noch inkrementellere Verbesserungen.
Als User werde ich die 4.0.1 dennoch schon einsetzen, denn offen gesagt, mir ist wichtiger dabei zu sein, als nur abzuwarten. Zumal ein KDE3/4 Mix möglich ist.
auf KDE passt eine solche Vorgehensweise schlecht, schon alleine, weil es bei KDE immer bekannte Fehler gibt, die auch im nächsten Release nicht behoben werden.
Das System ist zu komplex, um fehlerfrei zu sein, bisweilen sind die Ansätze nur Versuche, die auf krude Weise funktionieren.
Bei KDE und Gnome gibt es darum einen eher zeitgesteuerten Verlauf von Releases. Darin wird nur geregelt, bis wann was gemacht werden kann und darf, und was wann nicht mehr.
Das ist darum nötig, weil KDE-Entwicklung nicht alleine von Entwicklern getrieben wird. Es gibt noch Übersetzer, Künstler, Dokumentierer, Tester, Experten für UIs, etc. die in einer Entwicklung nicht mitmachen können, sondern die Releases brauchen.
Wenn KDE 4.0 nicht pünktlich fertig wird, heisst das, diese ganze Gruppen nicht konstruktiv an KDE teilnehmen können. Die Leiter von KDE wollen weder die Entwickler zu lange auf Feedback warten lassen, noch die anderen aussen vorlassen.
Realistisch war es immer so, dass die Versionen 2.0.0 und 3.0.0 unbenutzbar waren, im Vergleich zu den Endpunkten der Vorgänger-Serien. Aber auch notwendige Zwischenschritte für ein solches Projekt. Solche Releases sind Pilotversionen, die mehr Potential, aber weniger Qualität haben, als die Vorgängerlinie.
Nach dem traditionellen Schema dürfte KDE noch nicht mal Beta releasen, weil Plasma noch nicht fertig ist (damit wurde erst spät begonnen).
Übrigends hat der Linux-Kernel das alte Release-Schema völlig aufgegeben, weil es einfach nicht funktioniert, lange Entwicklungszyklen mit fehlerfreien Versionen abzuschliessen.
Bei Linux hatte man da aber auch schon den Luxus, das Design richtig zu haben. Bei KDE könnte es passieren, dass es keine 5.0 mehr gibt, sondern auch nur noch inkrementellere Verbesserungen.
Als User werde ich die 4.0.1 dennoch schon einsetzen, denn offen gesagt, mir ist wichtiger dabei zu sein, als nur abzuwarten. Zumal ein KDE3/4 Mix möglich ist.
Gruss,
Kay