Re: Let's get rid of the separate minor version numbers for shlibs - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Let's get rid of the separate minor version numbers for shlibs
Date
Msg-id 20160815211155.GL4028@tamriel.snowman.net
Whole thread Raw
In response to Re: Let's get rid of the separate minor version numbers for shlibs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Let's get rid of the separate minor version numbers for shlibs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Peter,

* Peter Eisentraut (peter.eisentraut@2ndquadrant.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

pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: PATCH: Exclude additional directories in pg_basebackup
Next
From: Tom Lane
Date:
Subject: Re: New version numbering practices