There is a long-running thread on pgsql-hackers on whether 9.6 should instead be called 10.0. Initially, opinions were mixed, but consensus seems now to have emerged that 10.0 is a good choice, with the major hesitation being that we've already released 9.6beta1, and therefore we might not want to change at this point. That doesn't seem like an insuperable barrier to me, but I think it's now time for the discussion on this topic to move here, because:
1. Some people who have strong opinions may not have followed the discussion on pgsql-advocacy, and
2. If we're going to rebrand this as 10.0, the work will have to get done here.
The major arguments advanced in favor of 10.0 are:
- There are a lot of exciting features in this release.
- Even if you aren't super-excited by the features in this release, PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes sense to bump the version based on the amount of accumulated change between then and now.
Thoughts? Is it crazy to go from 9.6beta1 to 10.0beta2? What would actually be involved in making the change?
From a non-hacker...
From a DBA/application-developer perspective while there are many exiting
features in 9.6 I'd expect more from 10.0, like some of these features:
- Built in "Drop-in replacement" Multi-master replication
- Built-in per-database replication with sequences and DDL-changes
(future versions of pglogical might solve this)
- Full (and effective) parallelism "everywhere"
- Improved executor (like Robert Haas suggested), more use of LLVM or similar
- All of Postgres Pro's GIN-improvements for really fast FTS (with proper, index-backed, sorting etc.)
- Pluggable storage-engines
I'm willing to declare that the likelihood you getting all of these in one release is zero. And there will always be "one more feature left".
I don't think anyone expects all of them for a 10.0 release:-) I just listed some stuff which would, IMHO, validate a 10.0 release, some combined with others, others alone (like MMR).
