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?
regards, tom lane
