Re: The case for version number inflation

> Most importantly, if we were going to call this release 10.0, I'd feel
> a lot happier committing certain more risky looking patches. Deciding
> this at the last minute is kindof confusing there.

We've always picked version numbers after we had the feature list. What
features do you feel are on the fence? I had the impression that
logical replication, for example, was pretty far from being done.

> * 9.0 was built-in replication support
> * 8.0 was the ability to run natively under Windows rather than needing
> Cygwin
> * 7.0 I'm less clear on, probably adding foreign key support I would guess
>
> So was foreign key support a more major change than other things in 6.x
> or 7.x such that it led to a first digit change? Or was the version
> change more arbitrary at that time?

7.0 was because Postgres became crash-safe, and stopped crashing routinely.

> Going forward, if we wish to follow the precedents set before, what kind
> of new feature would be major enough, relative to others, to warrant a
> 10? If in doubt, I'd say just keep incrementing 9.x, or arbitrarily
> switch at 9.5.

Well, if we get streaming logical replication in 2014, I'd say that's a
good candidate for 10.0. I don't expect that we'll do 9.4.

We'll have polished off a lot of the items in the major todo list,
binary replication will be "complete" at that stage, we'll have database
federation, and if you look at the cumulative changes between 9.0 and
9.4, it's a whole different database.

Other potential changes I can think of worthy of a major version bump:

* auto-sharding (i.e. "web scale")
* zero-downtime upgrade-in-place
* pluggable API for DB access (i.e. "PostNoSQL")
* a package of other PostSQL features (per Jacob's talk).
* pluggable storage
* robust database federation (although we seem likely to get that at the
same time as logical rep)

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com