DeviceKit-power release next Monday

[David Zeuthen]

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). 

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. 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.

> >  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.

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).

    David