Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 - Mailing list pgsql-hackers
| From | Oleg Bartunov |
|---|---|
| Subject | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
| Date | |
| Msg-id | CAF4Au4w2gsGjGWJnSkbJ7w-eDBprG_eARYP5qdgxbMQriPrNiw@mail.gmail.com Whole thread Raw |
| In response to | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Josh berkus <josh@agliodbs.com>) |
| Responses |
Re: Lets (not) break all the things. Was: [pgsql-advocacy]
9.6 -> 10.0
("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Robert Haas <robertmhaas@gmail.com>) Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Bruce Momjian <bruce@momjian.us>) |
| List | pgsql-hackers |
On Tue, Apr 12, 2016 at 9:25 PM, Josh berkus <josh@agliodbs.com> wrote:
Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We don't have clear roadmap and that's why we cannot plan future feature full release. There are several postgres-centric companies, which have most of developers, who do all major contributions. All these companies has their roadmaps, but not the community. I think 9.6 release is inflection point, where we should combine our roadmaps and release the one for the community. Than we could plan releases and our customers will see what to expect. I can't say for other companies, but we have big demand for many features from russian customers and we have to compete with other databases. Having community roadmap will helps us to work with customers and plan our resources.
On 04/12/2016 10:43 AM, Robert Haas wrote:
> 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.
+1
> 2. Small backward compatibility breaks are OK, but don't require doing
> anything special to the version number.
+1
> 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.
+1
> 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.
+1
Here's the features I can imagine being worth major backwards
compatibility breaks:
1. Fully pluggable storage with a clean API.
2. Total elimination of VACUUM or XID freezing
3. Fully transparent-to-the user MM replication/clustering or sharding.
4. Perfect partitioning (i.e. transparent to the user, supports keys &
joins, supports expressions on partition key, etc.)
5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables
without pg_upgrade or other modification).
6. Fully pluggable parser/executor with a good API
That's pretty much it. I can't imagine anything else which would
justify imposing a huge upgrade barrier on users. And, I'll point out,
that in the above list:
* nobody is currently working on anything in core except #4.
We are working on #3 (HA multimaster).
* we don't *know* that any of the above items will require a backwards
compatibility break.
People keep talking about "we might want to break compatibility/file
format one day". But nobody is working on anything which will and
justifies it.
Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We don't have clear roadmap and that's why we cannot plan future feature full release. There are several postgres-centric companies, which have most of developers, who do all major contributions. All these companies has their roadmaps, but not the community. I think 9.6 release is inflection point, where we should combine our roadmaps and release the one for the community. Than we could plan releases and our customers will see what to expect. I can't say for other companies, but we have big demand for many features from russian customers and we have to compete with other databases. Having community roadmap will helps us to work with customers and plan our resources.
--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pgsql-hackers by date: