On Wed, 2006-11-29 at 15:36 +0100, Free Ekanayaka wrote: > I'm sorry but I have to bother you again with the versioning issue of > the jack package. > Here below is a copy of the reply I sent to Paul Davis on the Jack > mailing list. It seems that this issue is making life harder for > people wanting to compile and run bleeding-edge versions of jack. > Is there some kind of compromise we could reach?
The original versioning scheme was decided upon by Junichi and me mainly due to lines 40-42 in the configure.ac file. The policy was stressed many times on the jack mailing list. http://jackit.cvs.sourceforge.net/jackit/jack/configure.ac?revision=1.84&view=markup 30 dnl --- 31 dnl HOWTO: updating the libjack interface version 32 dnl 33 dnl current = incremented whenever the public libjack API is changed 34 dnl revision = incremented when the libjack implementation is changed 35 dnl age = current libjack is both source and binary compatible with 36 dnl libjack interfaces current,current-1,...,current-age 37 dnl 38 dnl Note! see libtool documentation for detailed documentation 39 dnl 40 dnl Note Also! until we reach CURRENT>=1, the rules are somewhat 41 dnl slacker than this, and closer to those for the JACK version 42 dnl number. 43 dnl --- 44 JACK_API_CURRENT=0 45 JACK_API_REVISION=23 46 JACK_API_AGE=0 The only reliant verioning information then is the actual version number. The additional problem is that libjack has _two_ interfaces which are versioned. The one between the clients and the lib and the one between the server and the clients (acting via the lib). If the versioning is now as strict as the HOWTO specifies, the actual soname can be used for the package name. Robert. -- Robert Jördens <[EMAIL PROTECTED]>
