Alvaro Herrera <> writes:
> Tom Lane wrote:
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.

> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.

No, the argument for it was that we'd no longer have to have the annual
discussions about "is it 10.0 yet?".  There was no claim that getting
there would be uncontroversial, only that things would be quieter once
we did get there.

Considering that same long-term viewpoint, I'm not very happy about the
idea of "let's reserve the middle digit for compatible feature backports",
because the minute we set up a numbering system like that, everybody and
his brother will be arguing for making a branch on which to backport their
favorite more-or-less-compatible new feature.  You as well as others
pointed out that we don't have the manpower to actually support any such
thing ... so let's not open the door to it.

If we do arrive at a consensus that going to simply "10.0, 10.1, etc"
would be too much change, then I'd be in favor of adopting the
every-ten-year rule instead, in hopes that we can at least shut down
future "is it 10.0 yet" threads more quickly.  But that really does
nothing at all to fix the confusion so often shown by outsiders about
the significance of our version numbers.

                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to