Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > We can rectify the mistake, but then we need to change the SONAME.
> > That's what it's for.
>
> Well, if you just want to bump libpq's SO_MAJOR_VERSION, I won't object.
>
> This brings up a point that I think has been discussed before: we
> operate on the assumption that incrementing SO_MINOR_VERSION is enough
> to distinguish different releases of libpq, but in point of fact it
> is not. The Linux conventions for library names, for one, essentially
> require us to bump SO_MAJOR_VERSION for every release if we want to have
> any hope of letting different versions coexist. Perhaps our convention
> should be to bump SO_MAJOR_VERSION for each of our major releases and
> only use SO_MINOR_VERSION when we change a library in a dot-release.
According to our RELEASE_CHANGES documentation:
The major version number should be updated whenever the source of the
library changes to make it binary incompatible. Such changes include,
but are not limited to:
1. Removing a public function or structure (or typedef, enum, ...)
2. Modifying a public functions arguments.
3. Removing a field from a public structure.
so while I don't think we need to update the major number for every
PostgreSQL major release, the removal of prog_name probably required a
major bump.
Oops.
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
