DeviceKit-power release next Monday

David Zeuthen david at fubar.dk
Wed Oct 7 11:14:07 PDT 2009


On Wed, 2009-10-07 at 19:34 +0200, Kévin Ottens wrote:
> Still, I'm surprised that you'd bump it that often. Twice a year seems a lot 
> to me.

I just made "twice a year" up because asking users of the ABI to do
something twice a year isn't that unreasonable. If we never made any
mistakes we'd never need to break ABI. But that's not reality. I'll try
not to break ABI too much, it's just as painful for me as for you. Maybe
even more, since I work for a vendor and get to sort out the distro side
of the thing as well.

> Maybe another option would be to have a kind of staging area for not yet 
> stabilized parts of the ABI? Not sure how we could to it in practice while 
> keeping that convenient on the DK-* developers side. Two ideas come to my 
> mind:
>  1) Have the non stabilized bits of the ABI under sub-interfaces (e.g. 
> org.freedesktop.DeviceKit.Disks.Experimental);
>  2) Have the non stabilized bits of the ABI annotated and documented as such.
> 
> This way we'd have the choice to use the bleeding edge and maybe have to 
> transition twice a year, or be conservative and have more stability guarantee 
> (that what we use would break only at the next feature-version bump).
> 
> But I've been disconnected from the DK-* development for a while, I'm not sure 
> which one is the most realistic.

I don't know. It kinda feels over-engineered to do it that way. Probably
worth just crossing that bridge when and if we get there. I don't expect
to add a lot of different D-Bus interfaces either.

> Yup, having some headups is the minimum. The trouble is more that distros 
> don't transition at the same time, or don't backport my changes to support the 
> latest version, etc. It's real experience I got from HAL and I end up with 
> lots of BRs.

This I don't understand. HAL has kept a stable ABI for a very long time
(since March 7, 2005 when 0.5.0 was releasted). Which I believe is
before you got involved.

     David




More information about the devkit-devel mailing list