Alvaro Herrera <alvhe...@2ndquadrant.com> 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers