Re: Libtool versioning made easy (was Re: Converting libraries andpluginsto use gtk3
- From: dmacks netspace org
- To: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Libtool versioning made easy (was Re: Converting libraries andpluginsto use gtk3
- Date: Thu, 01 Jul 2010 02:15:36 -0400
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
> 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
> 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.
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:
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.
dmacks netspace org
] [Thread Prev