changing the enum type

[Richard Hughes]

On Mon, 2009-03-02 at 10:56 -0500, David Zeuthen wrote:
> On Mon, 2009-03-02 at 15:49 +0000, Richard Hughes wrote:
> > On Fri, 2009-02-27 at 11:03 -0500, David Zeuthen wrote:
> > > On Fri, 2009-02-27 at 15:25 +0000, Richard Hughes wrote:
> > > > Right, but using EggDBus the enums would be uint types, 
> > > We'd probably want to change something else but that's fine, we've never
> > > promised DeviceKit-power was ABI stable (btw, time you do a release
> > > please explicitly state it in the NEWS file). 
> > 
> > Right, but it is API stable. I'm using it in gnome-power-manager and
> > it's going to be used in the xfce power manager too. I've also started
> > porting other applications to use the interfaces rather than HAL.
> 
> I _very strongly_ disagree we want to mark this as stable API. It's just
> too early, especially when we are still committing API that turn out not
> to work well

Sure, I and you know the API is unstable. But Joe Bloggs doesn't know
that, and starts to build an application around it. I'm not explicitly
marking it stable, I'm just pointing out that when we release this,
people start using it, and expect it to keep working. It's not like
we're shipping a shared library with headers that have a
I_KNOW_THIS_IS_UNSTABLE define.

For the moment, I'll do as you suggest and mark it as unstable in the
NEWS file next time I do a release.

> (cf. the .Wakeup interface)

What's wrong with it?

> > > Exactly for reasons like the EggDBus one and also things like this enum
> > > one. So if you want to change it, just go for it I think.
> > > (But since g-p-m now depends on DeviceKit-power, do you think it's a
> > > good idea to break ABI? I mean, you'd need to through the motions of
> > > revving the external dep version for GNOME 2.26 with the GNOME release
> > > team and all.)
> > 
> > Yes, which is why I'm not exactly enamoured with the 001 style of
> > version numbers. Using the old major.minor.release version numbers I
> > could branch the tree and maintain an old and new branch. Using the 00x
> > numbering always means we can't break ABI or API, which for a new
> > project is typically a death blow. In my opinion of course.
> 
> You can just do 00x.y. The version number is free form modulo the usual
> version number comparison scheme.

Okay, that works for me. Thanks.

Richard.