GNOME 2.32 plans
Hi,
as some of you might have heard, there is going to be a GNOME 2.32
release in September, GNOME 3.0 being delayed to next spring.
For a large number of modules, 2.32 is going to be a pure bugfix release
based on 2.30. Therefore I propose the following approach:
* For bugfix releases, we upload them to unstable and try to put
them in squeeze.
* For modules requiring GSettings, we keep the 2.30 version, maybe
with some backported bugfixes. GSettings is simply too fresh, we
don’t have enough hindsight and we don’t want to have to direct
users through 2 different configuration mechanisms.
* For modules not requiring GSettings but requiring other new
features in Glib or GTK+ 2.x, see later. I doubt we will have
many such modules.
Then there’s the case of Glib. Glib 2.26 will be backwards compatible,
but the introduction of GSettings causes some packaging changes. I’m not
too fond of risking to break reverse dependencies. Having this version
in squeeze will depend on the calendar, but I’m not too fond of risking
to break thousands of reverse dependencies. I guess we’ll have to see
how the freeze is coming when it’s out.
For GTK+ 2.22, things are in a similar state. Even larger packaging
changes are being introduced because gdk-pixbuf was split in a separate
module. However I’d prefer to see it in squeeze, otherwise backporting
GTK+ 3.0 will be very hard. Of course I’m only proposing it since it
doesn’t use GSettings.
For GTK+ 3.0, the plan is to rely on backports since we don’t even have
a release date. If we ever happen to see it available during early
freeze time, we can try to squeeze it in. But in any case, direct or
indirect dependencies of meta-gnome2 must not depend on it. It would be
just so that GTK+ 3 applications can be built on squeeze without
backports.
Do you think this is realistic?
--
.''`.
: :' : “Fuck you sir, don’t be suprised when you die if
`. `' you burn in Hell, because I am a solid Christian
`- and I am praying for you.” -- Mike
Reply to: