As Peter mentioned in
https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4...@2ndquadrant.com
the decision has been taken to simplify our user-facing version numbering
system to be a two-component number. Since there have been questions
about the details of that, I wanted to emphasize that we are not breaking
compatibility with code-facing version numbering. In particular,
PG_VERSION_NUM and related representations will look like 1000xx, 1100xx,
etc in future branches, as though the second component were zero in an
old-style version number.
Somebody needs to come up with a patch implementing this changeover.
I will work on it if no one else feels motivated to (but I'd be just as
happy to let someone else do it). If we do not have such a patch ready
to go when the 9.6 branch is made on Aug 15, I will probably transiently
stamp HEAD as 9.7 rather than have a situation where "version 10" appears
in a three-part version number. (External code will need some cue as
to how to format displays from PG_VERSION_NUM, so we should have a hard
and fast rule that major >= 10 means new style.)
Also, it strikes me that we need a new convention for how we talk about
release branches informally. Up to now, mentioning say "9.5" without
any further qualification in a PG-list message was usually sufficient
to indicate a branch number, but I do not think that will work so well
if one just writes "10". I'm tempted to start writing branch numbers
as something like "PG10" or "v10". Thoughts?
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
