Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 - Mailing list pgsql-hackers

From Justin Clift
Subject Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Date
Msg-id CAAF273F-DE62-42ED-B5F5-81CF6D3227E9@postgresql.org
Whole thread Raw
In response to Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 12 Apr 2016, at 17:23, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 11:39 AM, Justin Clift <justin@postgresql.org> wrote:
>> Moving over a conversation from the pgsql-advocacy mailing list.  In it
>> Simon (CC'd) raised the issue of potentially creating a backwards-compatibility
>> breaking release at some point in the future, to deal with things that
>> might have no other solution (my wording).
>>
>> Relevant part of that thread there for reference:
>>
>>  http://www.postgresql.org/message-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com
>>
>> Simon included a short starter list of potentials which might be in
>> that category:
>>
>>  * SQL compliant identifiers
>>  * Remove RULEs
>>  * Change recovery.conf
>>  * Change block headers
>>  * Retire template0, template1
>>  * Optimise FSM
>>  * Add heap metapage
>>  * Alter tuple headers
>>  et al
>>
>> This still is better placed on -hackers though, so lets have the
>> conversation here to figure out if a "backwards compatibility breaking"
>> release really is needed or not.
>
> A couple of points here:
> *) I don't think having a version number that starts with 10 instead
> of 9 magically fixes backwards compatibility problems and I think
> that's a dangerous precedent to set unless we're willing to fork
> development and support version 9 indefinitely including major release
> versions.
>
> *) Compatibility issues at the SQL level have to be taken much more
> seriously than other things (like internal layouts or .conf issues).
>
> *) We need to do an honest cost benefit analysis before breaking
> things.  Code refactors placed on your users puts an enormous cost
> that is often underestimated.  I have some fairly specific examples of
> the costs related to the text cast removal for example.  It's not a
> pretty picture.

Yeah.  Moving the discussion here was more to determine which items
really would need a backwards compatible break.  eg no other approach can
be found.

Seems I started it off badly, as no-one's yet jumped in to discuss the
initial points. :(

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi




pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GIN data corruption bug(s) in 9.6devel
Next
From: Teodor Sigaev
Date:
Subject: Re: GIN data corruption bug(s) in 9.6devel