On Wed, 2009-10-07 at 23:46 +0700, Mikhail Gusarov wrote:
> Twas brillig at 12:24:43 07.10.2009 UTC-04 when da...@fubar.dk did gyre
> and gimble:
>
> DZ> FWIW, I think our version numbers should probably be changed so it
> DZ> is easier for distros to coordinate this effort. E.g. we should
> DZ> probably have
>
> DZ> <feature-version>.<abi-version>.<release>
>
> That'd be nice.
Cool, I'll look into doing this.
>
> DZ> No, it is public ABI that is subject to change.
>
> Okay. As a sidenote: are there public APIs which are essentially frozen
> at all? Even POSIX changes, though slowly.
Many C ABIs are considered stable but keeps getting extended - the most
obvious ones are glibc, the G stack, GStreamer and so on. The
traditional C ABI rules allow for things like
- Adding symbols/functions/etc
- Adding a return value as long as it doesn't requires the caller
to free it
- You can add parameters to functions (with some caveats for
memory handling)
and probably more. I don't think there's a definite list of do's and
dont's anywhere.
Anyway, ABI stability is, as a concept, a bit blurry. For example, in
GObject-based ABIs, I don't think the class hierarchy counts as ABI - so
for example, you can inject a class between to well-known classes in the
inheritance chain. That happened in the G stack when GtkObject started
deriving from GInitiallyUnowned.
As far as I know, ABI stability rules for D-Bus interfaces are not
completely hashed out. But in my experience it closely follows what
people do in C and C++ - e.g. it's fine to add methods, signals and
properties.
David
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
