Обсуждение: Library versioning

Поиск
Список
Период
Сортировка

Library versioning

От
Michael Meskes
Дата:
If I change some stuff in a library that forces the user to recompile all
programs because it's not binary compatible I have to change the major
number right? But just changing the order in an enum datatype does not
exactly look like such a big change. But the only way to avoid this problem
is adding the new entries at the end of the enum. Or do I miss something
obvious here?

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!


Re: Library versioning

От
Alfred Perlstein
Дата:
* Michael Meskes <meskes@postgresql.org> [000918 05:03] wrote:
> If I change some stuff in a library that forces the user to recompile all
> programs because it's not binary compatible I have to change the major
> number right? But just changing the order in an enum datatype does not
> exactly look like such a big change. But the only way to avoid this problem
> is adding the new entries at the end of the enum. Or do I miss something
> obvious here?

If you re-order an exported emum you are going to complete break binary
compatibility, either bump the major or add the entries at the end.

However there's another problem even if you add at the end, namely
that if previously the 'default' doesn't describe the new values
then you also break compatibility, for instance:

Chapter 17. libpq - C Library

..
   At any time during connection, the status of the connection   may be checked, by calling PQstatus. If this is
CONNECTION_BAD,  then the connection procedure has failed; if this is CONNECTION_OK,   then the connection is ready.
Eitherof these states should be   equally detectable from the return value of PQconnectPoll, as   above. Other states
maybe shown during (and only during) an   asynchronous connection procedure. These indicate the current   stage of the
connectionprocedure, and may be useful to provide   feedback to the user for example. These statuses may include:
 
       CONNECTION_STARTED: Waiting for connection to be made. 
       CONNECTION_MADE: Connection OK; waiting to send. 
       CONNECTION_AWAITING_RESPONSE: Waiting for a response from the postmaster. 
       CONNECTION_AUTH_OK: Received authentication; waiting for backend startup. 
       CONNECTION_SETENV: Negotiating environment. 
   Note that, although these constants will remain (in order to maintain compatibility) an application should   never
relyupon these appearing in a particular order, or at all, or on the status always being one of these   documented
values.An application may do something like this: 
 
       switch(PQstatus(conn))       {           case CONNECTION_STARTED:               feedback = "Connecting...";
        break;
 
           case CONNECTION_MADE:               feedback = "Connected to server...";               break;   .   .   .
      default:               feedback = "Connecting...";       }
 



If you happened to add another error state or something that indicated
some other action was required you'd also be breaking compatibility.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


Re: Library versioning

От
Michael Meskes
Дата:
On Mon, Sep 18, 2000 at 11:17:19AM -0700, Alfred Perlstein wrote:
> If you re-order an exported emum you are going to complete break binary
> compatibility, either bump the major or add the entries at the end.

The later is what I did so far.

> However there's another problem even if you add at the end, namely
> that if previously the 'default' doesn't describe the new values
> then you also break compatibility, for instance:
> ... 
> If you happened to add another error state or something that indicated
> some other action was required you'd also be breaking compatibility.

If the library returns the value, yes. But in my case the library just
accepts two more values. So th eonly problem I can think of is that someone
would try to run a new binary against the old library.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!