version updates for libraries
abartlet at samba.org
Mon Apr 11 16:27:33 MDT 2011
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'
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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical