Re: Planning incompatibilities for Postgres 10.0 - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Planning incompatibilities for Postgres 10.0
Date
Msg-id 51A3F0C9.90600@2ndquadrant.com
Whole thread Raw
In response to Re: Planning incompatibilities for Postgres 10.0  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Planning incompatibilities for Postgres 10.0
List pgsql-hackers
<div class="moz-cite-prefix">On 05/27/2013 05:45 PM, Michael Paquier wrote:<br /></div><blockquote
cite="mid:CAB7nPqQtwgrVMEgPuKNGyVZCYZTWSg7NY9G46XcGZy0-Nh3-Rg@mail.gmail.com"type="cite"><pre wrap="">On Mon, May 27,
2013at 2:01 PM, Craig Ringer <a class="moz-txt-link-rfc2396E"
href="mailto:craig@2ndquadrant.com"><craig@2ndquadrant.com></a>wrote:
 

</pre><blockquote type="cite"><pre wrap="">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.

</pre></blockquote><pre wrap="">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.</pre></blockquote> I don't find bumping the major to be particularly helpful. 
Everyrelease brings major features - and some introduce major incompatibilities.<br /><br /> 8.4 introduced CTEs.<br />
8.3broke tons of client code with the removal of implicit casts to text.<br /><br /> It really depends on what features
youconsider 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.<br/><br /> I'm extremely tired of being told "I'm running PostgreSQL 8.x" or "I'm running PostgreSQL 9.x" and
havingto point out the version policy, the fact that there are four years and huge fixes/enhancements between 8.0 and
8.4,etc.<br /><br /> The version policy makes _no distinction_ between which digit changes in a major release:<br /><br
/>"PostgreSQL major releases include new features and occur roughly once every year. A major release is numbered by
increasingeither the first or second part of the version number, e.g. 8.2 to 8.3.<br /><br /> "Major releases usually
changethe internal format of system tables and data files. These changes are often complex, so we do not maintain
backwardcompatibility of all stored data. A dump/reload of the database or use of the pg_upgrade module is required for
majorupgrades."<br /><br /> and I strongly believe that we should drop the notion entirely.<br /><br /> ... <br /><br
/><preclass="moz-signature" cols="72">-- Craig Ringer                   <a class="moz-txt-link-freetext"
href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training &
Services</pre>

pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: adding import in pl/python function
Next
From: Craig Ringer
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0