From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, pgsql-advocacy <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: 9.6 -> 10.0 |
Date: | 2016-03-22 21:08:11 |
Message-ID: | CA+TgmobgMfnapvzus5YXweEDb5tk5R5ktQddR53_CWb660K28A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
On Tue, Mar 22, 2016 at 4:45 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> It would make more sense to declare a release 10.0 in advance at the May dev
> meeting, then work to put in a whole load of incompatibilities all into one
> release. i.e. a planned compatibility break, which is what everybody will
> think we have done if we declare 10.0. They will then be surprised if that
> all happens in 10.1 or some other time.
> My list of incompatibilities would be
> * SQL compliant identifiers
> * Remove RULEs
> * Change recovery.conf
> * Change block headers
> * Retire template0, template1
> * Optimise FSM
> * Add heap metapage
> * Alter tuple headers
> et al
A lot of these strike me as things that have never been discussed and
that there's no consensus to actually do. But I also don't think that
they'd require a 10.0 if we did do them. Why would we need a 10.0 to
add a metapage to the heap? Presumably that would be done in a fully
backward-compatible way, so no user impact.
In general, I'm pretty skeptical of the idea of having a release where
we just change a lot of things incompatibly. That seems like a recipe
for having a lot of users who stay with the last release prior to the
break for a very long time, or even give up on PostgreSQL altogether.
It could even lead to a fork. We've never done that before - bumps to
the first version number have always been driven by features, not
incompatibilities - and I think projects that have done it have often
not been too pleased with the results.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2016-03-22 21:16:43 | Re: Suitable response to Oracle? |
Previous Message | Justin Clift | 2016-03-22 21:02:23 | Re: Suitable response to Oracle? |