Re: Let's get rid of the separate minor version numbers for shlibs

Peter,

* Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
> On 8/15/16 3:06 PM, Tom Lane wrote:
> > That would give us an automatic annual change in the minor version.
> > If we ever made an incompatible change in a shlib, we could advance
> > its SO_MAJOR_VERSION but keep this rule for the minor version (there's
> > no law that says we have to reset the minor version when we do that).
>
> Let's look into getting rid of the minor versions altogether. They
> don't serve any technical purpose in most cases. Library packaging
> policies have evolved quite a bit over the years; maybe there is some
> guidance there to make this simpler.

Eh? Last I checked, we needed minor version bumps to ensure that
binaries compiled against later versions, which might use newer symbols,
don't try to link against older libraries (which wouldn't have those
symbols).

Thanks!

Stephen