Gtk plant neues Versionierungsschema
Nach den aktuellen Plänen soll es alle zwei Jahre eine stabile API geben und darauf die Entwicklung der nächsten Hauptversion von Gtk starten. Das geplante Versionierungsschema stößt bei einigen Entwicklern auf heftige Kritik.
- Rainald Menge-Sonnentag
In Toronto findet mit dem Gtk Hackfest derzeit ein Treffen der Gtk-Entwickler statt. Das ehemals im GIMP-Projekt entwickelte Toolkit bildet die Grundlage für zahlreiche Desktop-Umgebungen wie Gnome und Cinnamon. Auf dem Hackfest diskutierten die Entwickler laut einem Blog-Beitrag von Allison Lortie, wie sie eine stabile API schaffen könnten, aber gleichzeitig das Toolkit um neue Features erweitern können. Als Ergebnis haben sie einen Plan gefasst, der klare Richtlinien für die Versionierung vorsieht und laut dem Beitrag von allen Beteiligten begeistert angenommen wurde.
Hauptversionen im Zweijahresrhythmus
Demnach will das Team die Hauptversionen angefangen mit dem kommenden Gtk 4 im Zweijahresrhythmus veröffentlichen. Die Parallelinstallation verschiedener Hauptversionen soll ebenso problemlos möglich sein wie bisher. Die Varianten verwenden unterschiedliche Namen für die Bibliotheken und pkg-config sowie separate Header-Verzeichnisse. Gtk 2, 3 und 4 stehen sich somit nicht gegenseitig im Weg.
Die unterschiedlichen Minor Releases sollen halbjährlich erscheinen und jeweils eine gerade Nachkommastelle haben. Auf Gtk 4.0 folgen somit Gtk 4.2, 4.4 und 4.6, das den Zyklus der 4.x-Releases abschließen soll. Das Team erweitert mit den jeweiligen Updates die API und ABI, sodass sie untereinander nicht kompatibel sein werden. Das letzte Minor Release definiert schließlich die stabile API.
Gtk 4.0 ist nicht Gtk 4
Somit ist, wie der Blog es ausdrückt, Gtk 4.0 nicht Gtk 4, sondern die erste rohe Version davon, was etwa eineinhalb Jahre später zu Gtk 4 werden soll. Die Vorgehensweise beginnt nach den Vorstellungen des Teams bereits mit dem aktuellen Gtk 3: Version 3.26 soll die erste stabile API-Version sein.
Entwickler können ihre Software somit für die jeweils stabile Version entwickeln und für jeweils zwei Jahre dieselbe API verwenden. Wer dagegen die Minor Releases verwendet, muss sich regelmäßig um die jeweiligen Anpassungen kümmern. Die Gnome-Community wird voraussichtlich den jeweils aktuellen Stand verwenden, aber für kleinere Projekte warnt der Blog-Beitrag vor dem damit verbundenen Aufwand und der Verantwortung.
Reaktion auf Beschwerden
Nach einigen teils heftige Beschwerden reagierte Lortie mit einem weiteren Blog-Beitrag, der unter anderem die Nummerierung gegen den Vorwurf verteidigt, dass die jeweils stabile Version stets eine alte sei, weil sich bereits die kommende in Entwicklung befindet. Außerdem sei nicht klar erkennbar, ob Version x.6 tatsächlich stabil sei oder noch Änderungen folgen. Die Vorgehensweise sei laut Lorties Meinung sinnvoller, als mit Nummern wie 4.9 und 4.99 auf einen 5.0-Release zuzusteuern oder mit Gewalt semantische Versionierung zu verwenden. Gleichzeitig verspricht das Team, in Zukunft klar zu definieren, wann eine Version als stabil gilt, und sicherzustellen, dass sich Entwickler auf den stabilen Stand verlassen können. (rme)
