On Sat, May 14, 2016 at 8:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> There are lots of improvement which get done to in-memory data
>> structures that wouldn't require a pg_dump/pg_upgrade, which could in
>> principle be ported into prior major versions if we had the resources
>> (reviewing, testing, packaging) to do it, with an increase in the
>> middle number. Maybe we will never find the resources to do that, but
>> why should that assumption get baked into the numbering scheme?
>
> If we were to do that today, it'd just be an increase in the minor number.
> I don't see why we'd need to change that approach.
We've rejected back-patching such improvements in the past on the
grounds that it was at least theoretically possible that it would
negatively affect someone, even if it were a win overall for most
people, and users shouldn't be forced to adopt that risk in order to
get security or corruption bug fixes that go into the minor number
increments.
> The real blocking
> factors there are about manpower and stability of the resulting code, not
> about whether you need some special version numbering to describe it.
If we did overcome the man-power and stability problems, we would
certain run into the version numbering one pretty quickly, under both
the existing versioning system and the two-part system.
And I don't think that using something at least vaguely like SemVer is
really "special", if anything it is less special than either the
existing or the dominant proposal.
Cheers,
Jeff