Re: Planning incompatibilities for Postgres 10.0

On 28/05/13 11:48, Craig Ringer wrote:
> 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 Ringerhttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
Yes, I hate the Firefox style number inflation.

Cheers,
Gavin