Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
От | Bruce Momjian |
---|---|
Тема | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
Дата | |
Msg-id | 20160429153043.GC31894@momjian.us обсуждение исходный текст |
Ответ на | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, Apr 12, 2016 at 01:43:41PM -0400, Robert Haas wrote: > 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. Well, this is true for SQL-level and admin-level changes, but it does make sense to group pg_upgrade breaks into a single release. I think the plan is for us to have logical replication usable before we make such a change. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: