adam at indexdata.dk
Wed Mar 21 14:01:56 CET 2007
We are making a new major so version of YAZ' shared library.
For years, it's been major version 2, i.e. libyaz.so.2 . The
corresponding Debian and RPM packages was libyaz. This naming is in
violation of Debian policy. For the same reason, the offical Debian etch
name is libyaz2. At ID, we were too lazy to change it ourselves to libyaz2.
But with libyaz.so.3 there is no excuse not to. We *have* to change the
Debian pacakge name. And so the new lib package will be libyaz3. The
development packages will be libyaz3-dev which will conflict with
existing packages libyaz-dev.
libyaz-dev, libyaz3-dev can, of course, co-exist.
When we are changing the .so major version we are "free to" change both
API and binary layout.
If anybody have things they would like to change in a more radical, let
us know. It's also good to get suggestions like that anyway.. But it's
better to do it now than later.
As soon as libyaz3 is out, it's stable API wise.. And suggestions would
have to wait for libyaz4.
Note that libyaz3 does not mean YAZ 3. At least that's what not I
personally have in mind. The "official" version name is a more branding
than anything else. And they certainly don't have to be the same.
My suggestion would to step from YAZ 2.1.X (libyaz) to YAZ 2.2.X
(libyaz3). But if there are good to reasons to do otherwise, let us know.
I had some ZOOM changes in mind.. These were added to CVS. These changes
are now "reverted". Thanks to Mike Taylor. One of the problems in making
changes to the ZOOM API, is that bindings may be really harmed by this.
For example, the ZOOM.NET would now "know" that some functions would now
have different prototypes. And so, an API change would go "unnoticed"
and just break at public demonstrations, etc.
It seems that for Windows, it would also be a good idea to change the
DLL name from YAZ.DLL to YAZ3.DLL. Suggestions to alternative ways are
More information about the Yazlist