On 2016-04-05 6:21 PM, Joshua D. Drake wrote:
> There will be a compatibility break, it will have to happen. That said, there
> are ways to mitigate a good portion of the concerns.
>
> 1. Make sure the release before the compatibility break is supported for longer
> than usual (say 7 instead of 5 years)
>
> 2. Announce the compatibility break AT LEAST 2 versions before it happens
>
> 3. Make sure we have some kind of utility that can deal with it, this might be
> something that rewrites the pages or perhaps we rely on logical replication?
I think you should explain better what you mean by point 2.
You only REALLY need to announce a compatibility break at the time of the break,
eg, this new version is incompatible in these ways, and if you're not ready to
compensate for it, stick with the prior version, which will be supported for
longer time.
The only reason I see to declare a break so far in advance is if in concert you
are making related changes to the prior versions, for example that they would
produce warnings (which can be disabled) on any action that will later break
with a subsequent upgrade, or if the breaks are of the kind that you can support
the new way and old way at once, so people can convert to something that will
work post-break while still being on the pre-break version; or otherwise there's
still the warnings.
The other reason for pre-announcement is so the Postgres devs have a long time
to think about the break in an are-you-sure manner, and announcing its
possibility with a release is forcing more scrutiny, where feedback can possibly
change its course.
Otherwise, what did you have in mind?
-- Darren Duncan
