Re: Planning incompatibilities for Postgres 10.0

On 05/27/2013 05:45 PM, Michael Paquier wrote:
> On Mon, May 27, 2013 at 2:01 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>
>> On 05/25/2013 05:39 PM, Simon Riggs wrote:
>> - Switching to single-major-version release numbering. The number of
>> people who say "PostgreSQL 9.x" is amazing; even *packagers* get this
>> wrong and produce "postgresql-9" packages. Witness Amazon Linux's awful
>> PostgreSQL packages for example. Going to PostgreSQL 10.0, 11.0, 12.0,
>> etc with a typical major/minor scheme might be worth considering.
>>
> In this case you don't even need the 2nd digit...
> Btw, -1 for the idea, as it would remove the possibility to tell that a new
> major release incrementing the 1st digit of version number brings more
> enhancement than normal major releases incrementing the 1st digit. This was
> the case for 9.0, helping people in remembering that streaming replication
> has been introduced from 9.x series.
I don't find bumping the major to be particularly helpful. Every
release brings major features - and some introduce major incompatibilities.

8.4 introduced CTEs.
8.3 broke tons of client code with the removal of implicit casts to text.

It really depends on what features you consider more major/significant.
Personally I don't think it makes sense to try to say "this release is
bigger" in Pg - at least not in terms of enhancement. I can see value in
using this-release-is-bigger for "this brings more breakage" - but would
strongly prefer a smooth and continuous release numbering that doesn't
confuse the heck out of users.

I'm extremely tired of being told "I'm running PostgreSQL 8.x" or "I'm
running PostgreSQL 9.x" and having to point out the version policy, the
fact that there are four years and huge fixes/enhancements between 8.0
and 8.4, etc.

The version policy makes _no distinction_ between which digit changes in
a major release:

"PostgreSQL major releases include new features and occur roughly once
every year. A major release is numbered by increasing either the first
or second part of the version number, e.g. 8.2 to 8.3.

"Major releases usually change the internal format of system tables and
data files. These changes are often complex, so we do not maintain
backward compatibility of all stored data. A dump/reload of the database
or use of the pg_upgrade module is required for major upgrades."

and I strongly believe that we should drop the notion entirely.

...

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services