Re: The case for version number inflation

On 1 March 2013 18:19, Josh Berkus <josh@agliodbs.com> wrote:
>> 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.

I think we need to avoid making decisions based upon impressions and
spend more time looking at facts, but that is beside the point.

Actually, I wasn't talking about logical replication at all.

> 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)

It should be incompatibilities or major architectural changes that
drive this, not simply new features.

And I think we should actually plan things ahead of time, so we can
save up lots of incompatibility patches and apply them all in one
release at the start of the cycle. Block format changes, syntax
changes, behaviour differences etc.

Numbering the release once we've seen what's in it doesn't help planning at all.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services