Re: The case for version number inflation

Here are my basic thoughts.

First I do not think that the inflationary numbering system will help our
adoption. The very conservative numbering system is part of our overall
image of "careful, stable, reliable." It goes with the elephant imagery
quite well.

There are a few problems I personally have with the current numbering
system as a practical matter but it may be the case that working on our
message regarding the numbering may be a sufficient answer here. The first
one is that the X.0 releases have tended to revolve around simplifying
marketing messages. 7.0 is crash-safe and has DRI. 8.0 runs on Windows
and supports PITR, 9.0 supports streaming replication. The X.Y.0 releases
can and sometimes do have large backwards-compatibility breaking changes
(dare I mention 8.3?) which are often far more significant than anything in
a .0 release.

What I am hearing from Simon's objections are the same thing, namely that
we aren't all on the same page regarding what these decisions mean. This
might be an opportunity to figure out what we should be telling the
community about the version numbers. Something like, "We come up with
whole number version numbers like 7.0, 8.0, or 9.0, when the new versions
have important, widely demanded features such that this simplifies our
message to decision-makers." From an application development perspective,
there is no special additional risk from 9.0 over 8.4. The big thing is
that it makes it easier to communicate which versions support replication.

I am fine with our current versioning system and I think it works to our
advantage. However I do think we could use some extra effort to make sure
we are on the same page regarding what these numbers mean.

I am in favor of keeping the current system, btw.

Best Wishes,
Chris Travers