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

On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After doing the tedious and easily forgotten (I almost did forget)
> minor version bumps for our shared libraries,
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0b9358d4406b9b45a06855d53f491cc7ce9550a9
>
> it suddenly struck me that in the brave new two-part-version-number
> world we could dispense with that annual task by hard-wiring the
> various shlibs' SO_MINOR_VERSION numbers to equal the current release
> branch's major version number, ie
>
> SO_MINOR_VERSION=$MAJORVERSION
>
> 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).
>
> This would be basically no change for libpq, since its scheduled
> minor version number for this release cycle happens to be 10 anyway.
> ecpg's various shlibs are at SO_MINOR_VERSION 8 or 9, so they would
> basically skip a minor version number or two, but that seems fine.
>
> The only place where we'd have a problem is the ecpg preprocessor
> itself, which is scheduled to be at version 4.13 this year. However,
> that version number is purely cosmetic since AFAICS the only thing
> that gets done with it is to print it in response to -v and suchlike.
> I don't really see why ecpg has its own version number anyway ---
> why don't we go over to giving it the same version number as the
> rest of PG? So it would just print the PG_VERSION string in the places
> where it currently prints the numbers hard-wired in ecpg/preproc/Makefile.
>
> Thoughts?

Well, part of the motivation for moving to one part version numbers
was that it would be less confusing, but this seems like it would
create more confusing minor version numbers for shared libraries. I
think it would be strange to have a library that went from version
1.10 to version 2.11 without passing through 2.0 - 2.10. I wouldn't
rate that a critical defect, but if you don't like strange version
numbering conventions, I wouldn't pick that one.

I wonder if we could address this problem by setting the version
numbers using a formula based on the major version, instead of using
the major version directly. e.g. if something is scheduled to be 1.8
this year, make it 1.(VERSION - 2). Then, you'd only have to update
the formula when bumping the major version - e.g. if we go to 2.0 in
version 14, you'd change the formula at that time to 2.(VERSION - 14).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company