* Tom Lane wrote:
> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme. To be
> specific:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0. Etc cetera.
When threaded Postgres is introduced in 2021, the version goes from 13
to 14. Not quite worthy of that momentous occasion.
Losing a third of the version number means losing the ability to
differentiate between significant-but-still-incremental improvements and
(never-again)-stop-the-presses-this-is-great improvements; it's all just
another major version. (Unless you'd want to jump from 13 to 20,
effectively making the first digit special.)
Finally, from the, er, visual point of view, 10.1 and 10.2 look good and
modern, but what about 10.13, 10.17, 10.22?
* Elsewhere, Tom Lane wrote:
> There's also the problem that the current numbering scheme confuses> people who aren't familiar with the project.
Howmany times have> you seen people say "I'm using Postgres 8" or "Postgres 9" when asked> what version they're on?
Knowing only the first component would be very nearly as useless with
two-part version numbers as it is today. The conversation will continue
just the same:
- "No, what is the exact version?"
- ...
- "There have been several updates for that version since. Can you please update to the latest one and see if the
problempersists?"
In short, -1 from me, but I don't matter much ...
PS: Three of the five 9.x micro versions are prime right now. Any chance an extra 9.1 release could be arranged?
--
Christian
