Robert Haas <robertmh...@gmail.com> writes: > On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane <t...@sss.pgh.pa.us> 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).
> 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. Well, we could address that when and if we ever do a major-version sonumber bump. We have not done that in the last ten years and frankly I doubt we ever would; that would imply the sort of client API break that we don't like to make. > 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. Possibly, though I think arithmetic is not Makefiles' strong suit. In any case, I don't see a need for it right now, unless you're objecting to the ecpg version changes I outlined. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers