From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning incompatibilities for Postgres 10.0 |
Date: | 2013-05-27 23:03:01 |
Message-ID: | 20130527230301.GV15045@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier escribió:
> On Tue, May 28, 2013 at 12:36 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com>wrote:
> > You do -- they are used for minor releases, i.e. 10.1 would be a bugfix
> > release for 10.0. If we continue using the current numbering scheme,
> > 10.1 would be the major version after 10.0.
> >
> Sorry for the confusion. I meant that the 2nd digit would not be necessary
> when identifying a given major release, so I just didn't get the meaning of
> what Craig said. As you say, you would still need the 2nd digit for minor
> releases.
Well, that seems okay to me. We used to see a lot of people talking
about "Postgres 8.x" when they meant, say, 8.3; and now we have people
talking about "Postgres 9" when in reality they mean 9.1 or some other
specific major version. Having the second digit be part of the major
version number is a difficult idea to convey to external people.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-05-27 23:13:06 | Re: adding import in pl/python function |
Previous Message | David Fetter | 2013-05-27 22:52:27 | Re: Planning incompatibilities for Postgres 10.0 |