On Tue, Apr 12, 2016 at 12:32 PM, Justin Clift <justin@postgresql.org> wrote:
> 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. :(
I'm going to throw down the gauntlet (again) and say more or less what
I previously said on the pgsql-advocacy thread. I think that:
1. Large backward compatibility breaks are bad. Therefore, if any of
these things are absolutely impossible to do without major
compatibility breaks, we shouldn't do them at all.
2. Small backward compatibility breaks are OK, but don't require doing
anything special to the version number.
3. There's no value in aggregating many small backward compatibility
breaks into a single release. That increases pain for users, rather
than decreasing it, and slows down development, too, because you have
to wait for the special magic release where it's OK to hose users. We
typically have a few small backward compatibility breaks in each
release, and that's working fine, so I see little reason to change it.
4. To the extent that I can guess what the things on Simon's list
means from what he wrote, and that's a little difficult because his
descriptions were very short, I think that everything on that list is
either (a) a bad idea or (b) something that we can do without any
compatibility break at all.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company