Junichi Uekawa <[EMAIL PROTECTED]> writes: > > a) almost every upstream release of jack was binary incompatible with > > to the lder ones, thus the need for different package names. > > Note that the next jack release is most likely to be binary incompatible > again considering that iwai's amd64 64-bit-32-bit fix is being implemented.
For various reasons the JACK development team chose not to *promise* binary compatibility until we reach release 1.0.0. I'm not going to defend the lack of rigorous libtool versioning in the 0.x.x releases. I hope that will all soon be behind us. But, we have actually done a rather good job on binary compatibility. It pains me to get no credit for this. With only a few exceptions, most JACK releases in the past year or two *have* been binary compatible with the older versions. The new transport features and the amd64 sized int work we are doing *are* binary compatible with previous releases to a very high degree. Considerable effort was expended to make the old transport interfaces work as well as possible, despite the fact that they were experimental in the first place. Some old transport master functions will no longer work in the next release, but they should fail safely. The sized int work is binary compatible with the 32-bit x86 platform (but not the 64-bit AMD). There can always be bugs, but I have tested a number of old application binaries without seeing any problems so far. If I were a Debian user (which I am) relying on .deb packages for JACK (which I'm not), I would want you to treat these releases as compatible except in the rare cases they are known not to work. Nando's Planet CCRMA site has been distributing binary RPM packages for JACK this way all year. He has a large user following in the Linux Audio community and a well-deserved reputation for solid, reliable packages. Many of these applications (I'd guess 40 or 50) depend on JACK. Very few problems have been reported; none that I can recall. I think JACK 1.0.0 will be coming soon. We probably *will* break binary compatibility for that, but in return for a promise to hold things stable for a very long time. Then, the difficult position in which we have placed our binary packagers should become much more comfortable. Thanks for your patience thus far. ;-) Regards, -- Jack O'Quin Austin, Texas, USA
