DeviceKit-power release next Monday

[David Zeuthen]

On Wed, 2009-10-07 at 23:46 +0700, Mikhail Gusarov wrote:
> Twas brillig at 12:24:43 07.10.2009 UTC-04 when david at 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