GLib 2.26 release plans (and GApplication)
- From: Ryan Lortie <desrt desrt ca>
- To: desktop-devel-list gnome org
- Subject: GLib 2.26 release plans (and GApplication)
- Date: Tue, 07 Sep 2010 16:57:46 -0400
hello everyone
This is, in part, a followup to my earlier mail about how we are
planning to drop the existing GApplication API and in part an
announcement of our plans for the release of GLib 2.26.
We came to fairly solid agreement during the Gtk meeting today.
Here's a rough idea of what the GLib 2.26 release will look like:
- we have a few small remaining issues to fix up:
- some possible GDateTime changes
- some probable GDBus changes
- maybe something for GSettings too
all of these changes have the potential of introducing API/ABI
breaks, but they will likely be changes to relatively
infrequently used APIs.
- we will then create the glib-2-26 branch
- we will remove GApplication from the branch, without replacement
GApplication will remain on master for the time being
- we will do a 2.25.x release from the glib-2-26 branch after
GApplication has been removed
- we will release 2.27.0 from master (with today's GApplication)
- glib-2-26 branch will freeze for a short while followed by the
release of 2.26.0 (with no GApplication)
All of that will be done this month, in the order above.
In the future, master (and some unspecified 2.27.x release) will see
GApplication replaced with a new implementation thereof. We aim to
release GLib 2.28.0 in December alongside Gtk 3.0.
Applications tracking the 3.0 platform API should continue using
GApplication until the replacement version arrives. Applications
preparing for a release to go into GNOME 2.32 should consider one of the
following options:
- go back to libunique (which is GDBus-enabled these days)
- copy-paste today's GApplication code into your application
- something else
We're very sorry for the disruption caused by removing API at such a
late date in the cycle. The reason that we want to delay the
introduction of the new GApplication is so that it can be properly
reviewed in a non-rushed way -- precisely to prevent this sort of thing
from happening again.
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]