On Tue, Mar 22, 2016 at 4:45 PM, Simon Riggs <simon@2ndquadrant.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
