On Tue, Mar 22, 2016 at 5:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> All of the above have been discussed as some point in last decade as I
> recall, no doubt many more I forget. I made a point to add the one you had
> suggested, as well as suggestions from Heikki and others.
OK, but I never suggested that needed a 10.0. And I don't think any
of them do, except maybe if we change the storage format in a
backward-incompatible way. Which I think would be a bad plan.
> I didn't claim there was consensus to do any of them, but I'm pretty sure
> they need to be mentioned first to find out which ones would be agreeable.
Certainly, no argument there.
> "It could even lead to a fork". As could anything, I guess. Who would lead
> this fork, and why?
Well, sure, anything could lead to a fork. But specifically, if we
decide to make backward-incompatible changes and people don't think
it's worth upgrading, that could create problems for the project. A
fork is the worst case, where somebody decides to go maintain the code
from before those changes. More likely, people would end up just
staying on 9.99999 for a really, really long time.
My point is: I don't endorse the idea that we should EVER have a
release that involves a major incompatibilities. And smaller
incompatibilities can be introduced gradually over time, same as we've
always done. I think it's right to think that we should stamp 10.0
when we have a really good release with great features, same as we did
with 9.0 and 8.0 and 7.0 (IIUC).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
