DeviceKit-power release next Monday

[Kévin Ottens]

On Wednesday 7 October 2009 19:04:26 David Zeuthen wrote:
> On Wed, 2009-10-07 at 18:59 +0200, Kévin Ottens wrote:
> > On Wednesday 7 October 2009 18:46:45 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.
> >
> > Well, if feature-version is incremented when a non backward compatible
> > ABI change is made, I'll be able to live with this.
> 
> The idea was to increase abi-version with every non-backward compatible
> ABI change. The feature-version is for huge architectural changes (which
> also implies ABI changes) that completely changes things (such would be
> extremely rare).

OK, was unclear to me if you wanted to bump "abi-version" on any ABI change or 
only the non backward compatible ones.

> So if we did this, the version numbers would most likely just be 1.x.y
> with x jumping perhaps once or twice a year.

Still, I'm surprised that you'd bump it that often. Twice a year seems a lot 
to me.

I think the thing is that I'm more conservative in my use, while you'd want to 
always use the very latest feature which recently got out of the door 
(incentive which makes sense since you crafted said change yourself and are 
impatient to use it). Since it got quickly exposed you might still have 
modifications to make to stabilize it later on.

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.

> The main reason I want
> <feature-version> is to keep the version numbers bounded at 1.x.y -
> otherwise we'd quickly end up with version 5.0.1 and that just looks
> pretty dorky. It also allows for some marketing headroom (as in "Here's
> VERSION TWO!") when doing a completely new and awesome version.

Sure, makes sense. In particular with your clarification on abi-version.

> > >  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.
> >
> > Well, there's a difference between making it deep frozen and keeping
> > backward compatibility. That's definitely what worries me most here, I'm
> > not against every ABI change, but backward compatibility breakages will
> > definitely make my life unnecessarily harder.
> 
> Sure, no-one likes breaking ABI, not even me ;-). And that's why we want
> to do this relatively infrequently and ideally, in a fashion whereby
> users of the ABI will have some headsups.

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.

> But we do want to reserve the right to break ABI when needed because
> otherwise things end up getting very messy. Especially since a stated
> goal is that only toolkits and OS-vendor-provided apps should use the
> ABI (regular apps should use the toolkit stack).

Sure, that's the frequency of those breakages and the transition management in 
the whole ecosystem that makes it a pain.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091007/79efbd22/attachment.pgp