Peter Eisentraut <pete...@gmx.net> writes:
> On tis, 2011-06-14 at 13:50 -0400, Robert Haas wrote:
>> There are real problems with the idea of having one release where we
>> break everything that we want to break - mostly from a process
>> standpoint. We aren't always good at being organized and disciplined,
>> and coming up with a multi-year plan to break everything all at once
>> in 2014 for release in 2015 may be difficult, because it requires a
>> consensus on release management to hold together for years, and
>> sometimes we can't even manage "days".
> I have had this fantasy of a break-everything release for a long time as
> well, but frankly, experience from other projects such as Python 3, Perl
> 6, KDE 4, Samba 4, add-yours-here, indicates that such things might not
> work out so well.
> OK, some of those were rewrites as well as interface changes, but the
> effect visible to the end user is mostly the same.
Good point. I think the case that has actually been discussed is the
idea of saving up binary-compatibility breaks (on-disk format changes).
That seems sensible. It doesn't create a bigger problem for users,
since a dump/reload is a dump/reload no matter how many individual
format changes happened underneath. But we should be wary of applying
that approach to application-visible incompatibilities.
As far as Greg's proposal is concerned, I don't see how a proposed
addition of two columns would justify renaming an existing column.
Additions should not break any sanely-implemented application, but
renamings certainly will.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
