Re: [GNOME VFS] gob inside gnome-vfs ...
- From: Havoc Pennington <hp redhat com>
- To: Seth Nickell <snickell stanford edu>
- Cc: Joe Shaw <joe ximian com>, Michael Meeks <michael ximian com>, vfs <gnome-vfs ximian com>, gnome-hackers gnome org
- Subject: Re: [GNOME VFS] gob inside gnome-vfs ...
- Date: 18 Jun 2002 22:27:47 -0400
Seth Nickell <snickell stanford edu> writes:
> The GnomeVFS changes only affect module ABI and source compatibility,
> and even then only for a limited number of modules that actually used
> the old API. I believe there's precedent for this in GTK already, which
> even versions its modules so it can change for 2.2 (GnomeVFS has
> traditionally provided progressive versioning with full backward compat,
> you just didn't get new functionality on those modules). We're planning
> to radically break module ABI for 2.2, but provide a compatibility mode
> for loading old-style modules. The new interface will be GObject based,
> but old modules should be loadable using a GObject wrapper, so user's
> shouldn't be negatively affected.
If the removed functions are for modules only and not exported in the
normal headers then that works. If the removed functions could have
been used by applications and there was no indication that apps should
avoid them, then it does not work. "indication" really needs to mean
something like #define GNOME_VFS_PRIVATE_MODULE_INTERFACE to get these
prototypes, similar to PANGO_ENABLE_BACKEND. i.e. not just reference
docs notes.
> We plan to keep GnomeVFS 2.0 and 2.2 ABI compatible for client calls,
> though we're going to need to do a release of GnomeVFS 2.0.1 with some
> padding of several structs to make sure this is really feasible.
You had better hurry - the release candidate is long since out, and
the release is in less than a week. Changing the ABI after that is not
OK - which should not need to be said. Most other modules went through
and added padding a long time ago. Libraries depending on gnome-vfs
are already ABI frozen, and in principle they were not supposed to be
ABI-frozen until all their dependencies were. Moreoever, the .0
release of every lib was supposed to be ABI-frozen, so 2.0.0 should
have been. Now everyone has to rebuild everything at the last minute
to add this padding. :-(
Would it be acceptable if GTK 2.0.0 and 2.0.1 were not ABI compatible?
You should plan for 2.2, 2.4, and even 2.6 to be ABI-compatible; the
general plan from everyone I've talked to is that GNOME is not moving
to an ABI-incompatible platform for at least 2 years, and we are
trying for a release every 6 months. So that's at least 4 releases on
the same ABI. Of course gnome-vfs need not have new releases to
accompany each GNOME release. But if you break the ABI, I don't think
GNOME will use the new gnome-vfs for at least 2 years. Perhaps 3 or 4.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]