Re: Libtool versioning made easy (was Re: Converting libraries andpluginsto use gtk3

[dmacks netspace org]

On Wed, 30 Jun 2010 23:25:59 -0400, Behdad Esfahbod  wrote:
On 06/30/2010 05:07 PM, dmacks netspace org wrote:
 > >
 > >  The instructions give a clear flowchart about what sorts of library
 > > changes should result in what changes to the -version-info flag. It's
 > > pretty different from other tools' versioning flags because it can
 > > handle linkers with features linux's doesn't have that are cool and
 > > useful on those platforms. It seems like the kernel of this proposal is
 > > to not bother having read the docs and to subvert even the most basic
 > > interface versioning/stability goals just to get a pretty filename. dan
 >
 > My proposal is coming from frustration about how many times I
failed to update
 > the libtool version parameters correctly and ended up changing the
major .so
 > version without intending to do so.  If you read and analyze my proposal
 > correctly, it doesn't break any of the desirable properties of the libtool
 > versioning scheme you seem to like.
 >
 > True, my proposal assumes that:
 >
 >   - ABI is never broken unless major version is bumped.  This is a strict
 > requirement for all Platform libraries as well as many libraries we
externally
 > depend on.  Maybe not true for some Desktop libraries, but they
were not the
 > ones I was aiming for.
 
Alright, but...
 
>   - No API is added during minor releases.  I admit that as Pango maintainer
 > I've added one here or there over the years.  But then again, I got to say,
 > the rule is to not add any in normal circumstances.
 
Just so we're on the same page here packages are versioned
"major.minor.teeny, right"? So glib-2.16.x vs -2.18.x vs -2.20.x are
different minor releases. Aren't there tons of interface additions
going to each of those successive minor release series? Likewise for
gtk -2.16.x -> -2.18.x. I've never seen any guideline that the
development between even-value (stable) minor-version release-series
should endeavor not to add new interface items--why would gnome want to
prevent whole new feature-sets in its core stack?
 
> In summary, I think the proposal simplifies libtool versioning to a great
 > extent and reduces errors without introducing major drawbacks.
 
How about a simplified set of variables that are still manually
adjusted? Something like:
 
 INTERFACE_CHANGE=2
 INTERFACE_BREAK=2
 
when you change the interface (in any way) you bump I_C. When you break
backward compatibility, you also bump I_B. From those, easy to
calculate what libtool -version-info is sufficient to track SONAME and
to handle its other important linker flags.
 
That way developers simply affirm what they did rather than having them
not follow a non-policy at all, or occasionally add when they have to
without feeling guilty about it.
 
--
Daniel Macks
dmacks netspace org