version updates for libraries

[Andrew Bartlett]

On Mon, 2011-04-11 at 17:14 +0200, Stefan (metze) Metzmacher wrote:
> Hi Tridge, hi Rusty,
> 
> >>> but no need for a new Y version, 1.0.4 is enough as a new
> >>> function doesn't cause any incompatibility with previous library
> >>> versions.
> >>
> >> I think we should make it clear if we add new features and apply this rule
> >> for X.Y.Z versions:
> >>
> >> if X == 0:
> >>     /* X == 0, means there's no stable API/ABI yet */
> >>     - bug fixes and new features should trigger an update of Z.
> >>     - incompatible changes should trigger an update of Y.
> >> else
> >>     - important bug fixes should trigger an update of Z.
> >>     - new features should trigger an update of Y
> >>     - incompatible changes should trigger an update of X.
> >>
> >> It would be nice if we could add checks for this into the ABI checking code.
> > 
> > Ok, I can agree with this logic, having at least guideines splleed
> > clearly in a README is probably a nice first step.
> 
> Are you also fine with such a logic for talloc, tdb, tevent and ldb?

I've been thinking about what this would mean in practice:  

What is a new feature?  We have added a lot of additional functions to
ldb over the past little while, and all of them could be considered new
features.  It seems we would almost never use Z in this case.  

Or is the intention not to combine Y and Z quite so much, but to have Y
be 'uses tdb2 as default backend' or 'much improved indexing scheme'
etc?

How should we describe new features that are ABI compatible with a
previous ABI, but are significant improvements?

I guess part of this trouble comes from trying to combine a package
version with a library .so version.  I don't propose to change that, I
just thought I would note it. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org