New version numbering practices - Mailing list pgsql-hackers

As Peter mentioned in
https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4a7b@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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Combining hash values
Next
From: Simon Riggs
Date:
Subject: Re: PostgreSQL 10 kick-off