Re: 9.6 -> 10.0

On 2016-05-09 3:24 PM, Josh berkus wrote:
> On 05/09/2016 03:18 PM, Darren Duncan wrote:
>> Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
>> optionally more. MAJOR must be increased when a backwards-compatibility
>> break is made of any kind (such as removing a feature), otherwise MINOR
>> must be increased for any forwards-compatibility break (such as adding a
>> feature), otherwise PATCH must be increased for changes that shouldn't
>> break any kind of compatibility, except for fixing bugs or security
>> holes where the old behavior was not being relied on for any working
>> uses. MATURITY means eg alpha/beta/rc/production etc.
>
> That seems like that would be an argument against 10.0? Since we didn't
> break backwards compat?

To be clear, I am talking about backwards compatibility in a holistic sense,
both API *and* database cluster file format.

0. Start with the context of a standalone (not replicated) Postgres 9.5
database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using
those. A1 also includes the set of SQL/etc queries made manually by users.

1. Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2,
start Postgres servers P2, this all without making any changes to D1 or A1 which
includes not running pg_upgrade etc.

2. Use A1 for awhile without making any changes to it.

3. Shutdown the Postgres 9.6 servers P2, reinstall or use the previous Postgres
9.5 binaries P1, start Postgres servers P1.

If despite switching to 9.6 and then back to 9.5 without making any changes to
the application, everything just keeps working, then 9.6 is backwards-compatible
with 9.5 in the holistic sense.

When using 9.6 in the same way as 9.5 was used breaks the ability to use a
database cluster as is with 9.5, backwards compatibility is broken.

-- Darren Duncan