On Sat, May 14, 2016 at 8:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
