DeviceKit-power release next Monday
ervin at ipsquad.net
Wed Oct 7 10:34:53 PDT 2009
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
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
1) Have the non stabilized bits of the ABI under sub-interfaces (e.g.
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.
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
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091007/79efbd22/attachment.pgp
More information about the devkit-devel