libyaz3

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

/ Adam

_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list

Adam Dickmeiss wrote:
> We are making a new major so version of YAZ' shared
library.
..
> 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.

One of the things that crosses my mind is
Z_SRW_explainResponse
This struct contains another struct: Z_SRW_record
I would suggest making this a pointer. This wil make
Z_SRW_explainResponse invariant with respect to changes in
Z_SRW_record
(as might be handy to add a RecordId Field)

Maybe the same argument yields for other
structs-within-strucs as well.

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

This might be confusing. Why not take a big leap ;)

> / Adam

Ko van der Sloot
Tilburg University

_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list

Ko van der Sloot wrote:
> Adam Dickmeiss wrote:
>> We are making a new major so version of YAZ' shared
library.
> ..
>> 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.
> 
> One of the things that crosses my mind is
Z_SRW_explainResponse
> This struct contains another struct: Z_SRW_record
> I would suggest making this a pointer. This wil make
> Z_SRW_explainResponse invariant with respect to changes
in Z_SRW_record
> (as might be handy to add a RecordId Field)

OK.

> Maybe the same argument yields for other
structs-within-strucs as well.
We'll look into these issues. Thanks.

>> 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.
> 
> This might be confusing. Why not take a big leap ;)
You are the second to say that. The branded version can be
anything. So 
we can make that to follow, at least, the major lib.so
version.

Doing the other way around, however, is a no-go.

See
http://www.gnu.org/software/libtool/manual.
html#Updating-version-info

So new version would be YAZ 3?

/ Adam

> 
>> / Adam
> 
> Ko van der Sloot
> Tilburg University
> 
> _______________________________________________
> Yazlist mailing list
> Yazlistlists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list
> 
> 


_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list

Adam Dickmeiss wrote:
> Ko van der Sloot wrote:
>> Adam Dickmeiss wrote:
> You are the second to say that. The branded version can
be anything. So
> we can make that to follow, at least, the major lib.so
version.
> 
> Doing the other way around, however, is a no-go.
> 
> See
> http://www.gnu.org/software/libtool/manual.
html#Updating-version-info
> 
> So new version would be YAZ 3?

After trying to understand everything on that page, I'm not
so sure ;)

But I think it's allowed and convenient to relate libyaz3 to
a "new"
Yaz3.x line.
Whenever libyaz4 is needed, Yaz 4 will pop up. (and not
before)

> / Adam

Good luck
Ko


_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list