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

[Behdad Esfahbod <behdad behdad org>]

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.

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

In summary, I think the proposal simplifies libtool versioning to a great
extent and reduces errors without introducing major drawbacks.

behdad