| From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Josh berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, Thom Brown <thom(at)linux(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 10.0 |
| Date: | 2016-05-13 23:32:57 |
| Message-ID: | 236B13DC-2A1A-4AE3-A3EC-EEBA296F4FC3@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On May 13, 2016, at 11:31 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> Josh berkus wrote:
>
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
>
> I think the next version should be 10.0 no matter what changes we put
> in.
-1
If I understand correctly, changing the micro version means that one or more
bugs have been fixed, but that the on-disk representation has not changed. So
if I am running 9.3.2, I am at liberty to upgrade to 9.3.3 without a dump and
restore.
If the minor number has changed, new features have been added that require
a dump and restore. As such, on 9.3.2, I would not be at liberty to upgrade to
9.4.0 without some extra effort.
A major number change should indicate that something even bigger than on-disk
compatibility has changed, such as a change that precludes even a dump and
restore from working, or that breaks network communication protocols, etc.
Any project that starts inflating its numbering scheme sends a message to
users of the form, "hey, we've just been taken over by marketing people, and
software quality will go down from now on."
mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-05-14 00:00:31 | Re: 10.0 |
| Previous Message | Michael Banck | 2016-05-13 22:44:46 | Re: 10.0 |