Was etwas verwirrt: Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder wird nur halb gebrochen? Kläre mich doch bitte einer auf.
Von Christopher Roy Bratusek am Fr, 23. Oktober 2009 um 13:18 #
Also ich finde "gebrochene Programmierschnittstelle" für "broken API" finde ich nicht so toll, gibt es - außer "inkompatible P..." nicht noch was eleganteres? Bei so vielen Wörtern in unserer Sprache MUSS es etwas geben.
Mit GNOME3 wird dir API-kompatibilität gebrochen. So wie es momentan aussieht wird die nächste GNOME Version zu 99% GNOME3 sein.
Man will GNOME aber nicht auf biegen und brechen veröffentlichen und ein KDE4 fiasko erleben. Deswegen hat man sich vorbehalten im Notfall noch ein GNOME 2.30 einzuschieben (welches dann die API-kompatibilität nicht bricht, da es noch eine Version aus der 2er Reihe wäre) und danach erst GNOME3 zu veröffentlichen.
Es wird also zu 99% kein GNOME2.30 geben. Sollte es wieder erwartetnd doch noch ein GNOME2.30 geben, dann gelten da natürlich die gleichen Regeln wie für jede Version der 2er Reihe.
Ich frage ja nur, weil man das doch jetzt wissen müsste: Bricht man mit der API oder nicht? Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein. Daher kann man wohl kaum ein fast fertiges GNOME 3.0 als 2.30 bezeichnen, da dann ja schon API-Brüche im System sein müssten.
Mit GNOME3: Ja Mit einem möglichen (wenn auch sehr unwahrscheinlichen) GNOME2.30: Nein
>Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein.
Klar müssen die libs irgendwann eingebunden werden. Ein GNOME2.X Programm, dass keine veralteten API Elemente verwendet wird aber problemlos auf GNOME3 übersetzbar sein. Man kann also selbst dann, wenn alle GNOME Programme "GNOME3-ready" sind immer noch entscheiden ob man ein GNOME2.X oder ein GNOME3 macht. Sollten nicht alle "GNOME3-ready" sein, dann wird man wohl den GNOME2.30 weg gehen müssen. Das ist aber wie gesagt sehr unwahrscheinlich.
> Sag mir doch lieber mal, ob mit 2.30 nun die API geändert wird oder nicht. Das müssen die Entwickler doch schon wissen oder?
So lange die vorderste Zahl gleich bleibt, bleibt die Plattform garantiert nicht nur API-, sondern sogar ABI-kompatibel. Sobald die Major-Version (die erste Zahl in der Versionsnummer) sich ändert, ist ein Bruch der Kompatibilität (API und ABI) erlaubt, und, im Falle von Gnome 3, auch angekündigt.
> Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht?
Offensichtlich noch nicht, sonst würde die Versionsnummer bereits feststehen.
> Kläre mich doch bitte einer auf.
In der Software Entwicklung gibt es verschiedene Entwicklungsmodelle. Zur Zeit sehr populär sind Modelle welche auf "agiler Softwareentwicklung" basieren. Dabei gibt es mehrere Verschiedene Modelle, welche zwar in Strukturen und Abläufen unterscheiden, jedoch auf den gleichen Grundprinzipien entwickelt werden: möglichst flexibel auf Änderungen von Anforderungen reagieren zu können.
Ich kenne mich zu wenig mit den Strukturen in der Gnome Entwicklung aus um den Namen für das verwendete Modell nennen zu können. Durchaus üblich bei solchen Prozessen ist aber, dass Features, Datum, Versionsnummer nicht fest aneinander gekoppelt sind. Bei Gnome wird offensichtlich das Datum als feste Größe verwendet: alle 6 Monate gibt es ein Release. Das erfordert dass Features nicht fest an die Releasenummern gebunden sind, müsste man u.U. unfertige Software veröffentlichen. Zusätzlich gibt es bei Gnome noch die Regelung das Major Versions-Nummern nur erhöht werden wenn Kompatibilität gebrochen wird.
Es wird also zu einem festgelegten freeze Termin die Entscheidung getroffen welche Features den Weg in die Version 2.28+1 finden werden. Dabei wird nicht entschieden was man gerne hätte (das wurde bereits vorher entschieden), sondern welche der zukünftig geplanten Features bereits weit genug um realistisch zum festgelegten Release Termin fertig zu werden. Je nachdem welche Features das sind, wird mit Kompatibilität gebrochen (-> 3.0) oder nicht (2.30).
Dieses Modell hat den Vorteil, dass man dabei Regelmäßige, absehbare Releases machen kann. Dabei kommt man aber nicht unter Zeitdruck was unfertiges zu veröffentlichen, oder Releses lange Zeit nach hinten hinaus zu schieben. Davon abhängenden Projekten (wie z.B. Distributions Releases) erleichtert das die Planung deutlich.
Genau das ist auch der Grund warum sich ein gewisser Mr. Shuttleworth so für feste Deadlines in der OSS-Entwicklung einsetzt. Leider scheinen noch immer viele Leute das Konzept dahinter verstanden zu haben, und meinen feste Deadlines für zu schlechteren, unfertigen Code.
>Was etwas verwirrt: >Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder >wird nur halb gebrochen? >Kläre mich doch bitte einer auf.
Es wird einige veränderungen in der gtk3 api geben welche zu gtk2 inkomaptibel sind, es ist aber weiterhin möglich verschiedene gtk versionen gleichzeitig zu installieren. Sollte gnome 2.30 erscheinen besitzt es noch gtk2. Ab 3.0 gtk3
Weitere Informationen findest du hier: http://www.gtk.org/plan/
Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder wird nur halb gebrochen?
Kläre mich doch bitte einer auf.
Man will GNOME aber nicht auf biegen und brechen veröffentlichen und ein KDE4 fiasko erleben. Deswegen hat man sich vorbehalten im Notfall noch ein GNOME 2.30 einzuschieben (welches dann die API-kompatibilität nicht bricht, da es noch eine Version aus der 2er Reihe wäre) und danach erst GNOME3 zu veröffentlichen.
Es wird also zu 99% kein GNOME2.30 geben. Sollte es wieder erwartetnd doch noch ein GNOME2.30 geben, dann gelten da natürlich die gleichen Regeln wie für jede Version der 2er Reihe.
Mit GNOME3: Ja
Mit einem möglichen (wenn auch sehr unwahrscheinlichen) GNOME2.30: Nein
>Irgendwie müssen die richtigen Libs doch eingebunden werden und wenn ich das richtig verstanden habe, soll der Sprung auf GNOME 3.0 ja kein kleiner sein.
Klar müssen die libs irgendwann eingebunden werden. Ein GNOME2.X Programm, dass keine veralteten API Elemente verwendet wird aber problemlos auf GNOME3 übersetzbar sein. Man kann also selbst dann, wenn alle GNOME Programme "GNOME3-ready" sind immer noch entscheiden ob man ein GNOME2.X oder ein GNOME3 macht. Sollten nicht alle "GNOME3-ready" sein, dann wird man wohl den GNOME2.30 weg gehen müssen. Das ist aber wie gesagt sehr unwahrscheinlich.
So lange die vorderste Zahl gleich bleibt, bleibt die Plattform garantiert nicht nur API-, sondern sogar ABI-kompatibel. Sobald die Major-Version (die erste Zahl in der Versionsnummer) sich ändert, ist ein Bruch der Kompatibilität (API und ABI) erlaubt, und, im Falle von Gnome 3, auch angekündigt.
Also so wie bei KDE auch.
Offensichtlich noch nicht, sonst würde die Versionsnummer bereits feststehen.
> Kläre mich doch bitte einer auf.
In der Software Entwicklung gibt es verschiedene Entwicklungsmodelle. Zur Zeit sehr populär sind Modelle welche auf "agiler Softwareentwicklung" basieren. Dabei gibt es mehrere Verschiedene Modelle, welche zwar in Strukturen und Abläufen unterscheiden, jedoch auf den gleichen Grundprinzipien entwickelt werden: möglichst flexibel auf Änderungen von Anforderungen reagieren zu können.
Ich kenne mich zu wenig mit den Strukturen in der Gnome Entwicklung aus um den Namen für das verwendete Modell nennen zu können. Durchaus üblich bei solchen Prozessen ist aber, dass Features, Datum, Versionsnummer nicht fest aneinander gekoppelt sind. Bei Gnome wird offensichtlich das Datum als feste Größe verwendet: alle 6 Monate gibt es ein Release. Das erfordert dass Features nicht fest an die Releasenummern gebunden sind, müsste man u.U. unfertige Software veröffentlichen. Zusätzlich gibt es bei Gnome noch die Regelung das Major Versions-Nummern nur erhöht werden wenn Kompatibilität gebrochen wird.
Es wird also zu einem festgelegten freeze Termin die Entscheidung getroffen welche Features den Weg in die Version 2.28+1 finden werden. Dabei wird nicht entschieden was man gerne hätte (das wurde bereits vorher entschieden), sondern welche der zukünftig geplanten Features bereits weit genug um realistisch zum festgelegten Release Termin fertig zu werden. Je nachdem welche Features das sind, wird mit Kompatibilität gebrochen (-> 3.0) oder nicht (2.30).
Dieses Modell hat den Vorteil, dass man dabei Regelmäßige, absehbare Releases machen kann. Dabei kommt man aber nicht unter Zeitdruck was unfertiges zu veröffentlichen, oder Releses lange Zeit nach hinten hinaus zu schieben. Davon abhängenden Projekten (wie z.B. Distributions Releases) erleichtert das die Planung deutlich.
Genau das ist auch der Grund warum sich ein gewisser Mr. Shuttleworth so für feste Deadlines in der OSS-Entwicklung einsetzt. Leider scheinen noch immer viele Leute das Konzept dahinter verstanden zu haben, und meinen feste Deadlines für zu schlechteren, unfertigen Code.
Du meinst "nicht verstanden" zu haben und spielst auf GNOME an oder?
Nein, ganz im Gegenteil. Das sollte aber aus dem obigen Text hervorgegangen sein.
>Die nächste GNOME-Version heisst 2.30 oder 3.0. Wissen die denn noch nicht, ob die API nun gebrochen wird oder nicht? Oder >wird nur halb gebrochen?
>Kläre mich doch bitte einer auf.
Es wird einige veränderungen in der gtk3 api geben welche zu gtk2 inkomaptibel sind, es ist aber weiterhin möglich verschiedene gtk versionen gleichzeitig zu installieren. Sollte gnome 2.30 erscheinen besitzt es noch gtk2. Ab 3.0 gtk3
Weitere Informationen findest du hier: http://www.gtk.org/plan/