Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It is not real clear to me whether we need a major version bump, rather
> > than a minor one. We *do* need to signal binary incompatibility. Who
> > can clarify the rules here?
>
> Strictly speaking, it's platform-dependent, but our shared library code
> plays a bit of abuse with it. What it comes down to is:
>
> If you change or remove an interface, increment the major version number.
> If you add an interface, increment the minor version number. If you did
> neither but changed the source code at all, increment the third version
> number, if we had one.
My take on it is: if you break binary compatibility, which includes
semantic dependencies, then you increment the major version number.
Otherwise you increment the minor version number.
Since the change we're talking about apparently broke binary
compatibility, it calls for a major version number change.
Protocol incompatibility requires a different method of enforcement
altogether. Incrementing the major number of the library isn't going
to do you any good for that (7.2 clients on remote systems won't have
any idea that the libraries on the 7.3 server have changed that much).
All MHO, of course...
--
Kevin Brown kevin@sysexperts.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs:
<> Any questions?