On Wed, 30 Jun 2010 23:25:59 -0400, Behdad Esfahbod wrote:
On 06/30/2010 05:07 PM, [email protected] 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
[email protected]
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
