Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Aug 15, 2016 at 3:06 PM, Tom Lane <tgl@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
