headers
Behdad Esfahbod | 1 Jul 2010 05:25
Favicon
Gravatar

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

On 06/30/2010 05:07 PM, dmacks <at> 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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
dmacks | 1 Jul 2010 08:15

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


On Wed, 30 Jun 2010 23:25:59 -0400, Behdad Esfahbod  wrote:
On 06/30/2010 05:07 PM, dmacks <at> 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...
(Continue reading)

Permalink | Reply | 7 comments |
headers
Steve Frécinaux | 1 Jul 2010 10:15
Picon

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

On 07/01/2010 08:15 AM, dmacks <at> netspace.org wrote:

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

To be really usable, we would need to use three version variables and 
let libtool, autoconf or someone to infer the other values from there.

VERSION=2.22.5
LAST_INTERFACE_CHANGE=2.22.0
LAST_INTERFACE_BREAK=2.20.0

This is the only scheme that would not require extent knowledge on how 
libtool versioning works.
Permalink | Reply | 4 comments |
headers
Emmanuele Bassi | 1 Jul 2010 10:26
Picon
Gravatar

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

On Thu, 2010-07-01 at 02:15 -0400, dmacks <at> netspace.org wrote:
> 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?

odd-minor version release cycles are where the new API is added; between
micro releases of the same even minor version no new API is added - or,
alternatively: point releases during the same even minor cycle are
strictly interchangeable from a soname point of view. that's the general
rule followed by the GNOME platform libraries, and the scheme enforced
by Behdad's proposal (which, I may add, is already what GLib, Pango,
GTK, GdkPixbuf are using; and I also use it in non-platform libraries
that I maintain, like json-glib and Clutter).

ciao,
 Emmanuele.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Winship | 1 Jul 2010 15:58
Picon

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

On 07/01/2010 04:15 AM, Steve Frécinaux wrote:
> VERSION=2.22.5
> LAST_INTERFACE_CHANGE=2.22.0
> LAST_INTERFACE_BREAK=2.20.0

I like this (though I think you'll need a few more variables to make
this be able to pick up where the version numbers from the previous
system left off).

On 06/30/2010 11:25 PM, Behdad Esfahbod wrote:
> 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.

As the maintainer of a library in the Desktop set who routinely fails to
update the libtool versioning variables, I'd much prefer something that
makes fewer assumptions and works for Desktop libraries too. Eg:

>   - No API is added during minor releases.

I know it's naughty, but I do this all the time in libsoup if it lets
someone fix an annoying bug in some higher-up-the-stack package (usually
epiphany).

-- Dan
Permalink | Reply | 1 comment |
headers
Steve Frécinaux | 1 Jul 2010 16:48
Picon

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

On 07/01/2010 03:58 PM, Dan Winship wrote:
> On 07/01/2010 04:15 AM, Steve Frécinaux wrote:
>> VERSION=2.22.5
>> LAST_INTERFACE_CHANGE=2.22.0
>> LAST_INTERFACE_BREAK=2.20.0
>
> I like this (though I think you'll need a few more variables to make
> this be able to pick up where the version numbers from the previous
> system left off).

Actually, I considered the one implementing that would be able to rely 
on git tags for that.
Permalink | Reply | 0 comments |
headers
Behdad Esfahbod | 1 Jul 2010 17:35
Favicon
Gravatar

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

On 07/01/2010 04:15 AM, Steve Frécinaux wrote:

> VERSION=2.22.5
> LAST_INTERFACE_CHANGE=2.22.0
> LAST_INTERFACE_BREAK=2.20.0
> 
> This is the only scheme that would not require extent knowledge on how
> libtool versioning works.

I can do something like that too.

However, do the libraries that break ABI all the time, really bump their major
so-version with every break?

behdad
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Permalink | Reply | 1 comment |
headers
Behdad Esfahbod | 1 Jul 2010 17:38
Favicon
Gravatar

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

On 07/01/2010 02:15 AM, dmacks <at> netspace.org wrote:

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

This is very close to what we used to do before (and many libraries do today).
 However, it's very fragile and has resulted in many broken releases over the
years.

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

Easier said than done.  Ask anyone who maintains libraries...

behdad
Permalink | Reply | 0 comments |
headers
Josselin Mouette | 1 Jul 2010 18:46
Picon
Favicon

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

Le jeudi 01 juillet 2010 à 11:35 -0400, Behdad Esfahbod a écrit :
> However, do the libraries that break ABI all the time, really bump their major
> so-version with every break?

They don’t, and this breaks some systems. Any initiative that reduces
the amount of such breakage is welcome.

This is the kind of reason why we had, for example, to set a different
soname downstream for libeel.

Cheers,
--

-- 
 .''`.
: :' :      “Fuck you sir, don’t be suprised when you die if
`. `'       you burn in Hell, because I am a solid Christian
  `-        and I am praying for you.”   --  Mike

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Permalink | Reply | 0 comments |
headers
Jonh Wendell | 1 Jul 2010 19:21
Picon
Gravatar

Statistics on each release

Hello guys, I just read a xorg release announcement and found quite
interesting their statistics not only about people but also about
companies behind committers:
http://lists.x.org/archives/xorg-devel/2010-July/010706.html

Wouldn't be nice to have this in GNOME releases? :)

Cheers,
--

-- 
Jonh Wendell
http://www.bani.com.br
Permalink | Reply | 5 comments |

Gmane