Thread: New version numbering practices

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

On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote:
> 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?

I don't see 10 as ambiguous.  It's clear what's being talked about,
now that the decision has been made.

Best,
David.

"This one goes up to 11."
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Tom Lane wrote:

> 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?

I agree that writing just "10" might be confusing in some places, though
I also agree with dfetter than it might be obvious in other contexts.
Either "pg10" or "v10" look good to me.  Capitalizing it as PG10 is okay
though I'm not sure that most would bother (I probably wouldn't).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

David Fetter <david@fetter.org> writes:
> On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote:
>> 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?

> I don't see 10 as ambiguous.  It's clear what's being talked about,
> now that the decision has been made.

It's clear what's being talked about as long as you already know that
it is a version number.  But it seems to me that we have often relied
on the "x.y" notation itself to indicate that a version number is meant.
Consider someone writing "I'm doing that in 10."  Did he mean he's
writing a patch for version 10, or he's going to do that 10 minutes from
now, or what?  Over the past couple of months I have already found myself
writing "10.0" or "9.7^H^H^H10" to make it clear that I meant the next
release version, because just "10" seemed too ambiguous.  Maybe I'm
worried about nothing and the ambiguity mostly came from our not having
settled the two-or-three-part-version-number question, but I'm not sure.
        regards, tom lane

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> the lists.  I suspect the choice will be dependent on context and channel.

Hmm, that seems like a workable answer as well, and one that's traceable
to our past habits.
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > the lists.  I suspect the choice will be dependent on context and channel.
>
> Hmm, that seems like a workable answer as well, and one that's traceable
> to our past habits.

For my 2c, I'd kind of prefer v10, but I could live with 10.x.

Not sure that I have any real reason for that preference other than
'v10' is slightly shorter and seems more 'right', to me.  Perhaps
because '10.x' implies a *released* version to me (10.1, 10.2, 10.3),
whereas you asked about a *branch*, which would generally include some
patches past the latest point release.

In other words, "are you going to back-patch this to 10.x?" doesn't seem
quite right, whereas "are you going to back-patch this to v10?" lines up
correctly in my head, but I don't hold that distinction very closely and
either would work.

Thanks!

Stephen

On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > > the lists.  I suspect the choice will be dependent on context and channel.
> > 
> > Hmm, that seems like a workable answer as well, and one that's traceable
> > to our past habits.
> 
> For my 2c, I'd kind of prefer v10, but I could live with 10.x.
> 
> Not sure that I have any real reason for that preference other than
> 'v10' is slightly shorter and seems more 'right', to me.

10 is even shorter, and when we get to 15, it seems like it'll be
pretty silly still to be referring to the 9.x series.

> In other words, "are you going to back-patch this to 10.x?" doesn't
> seem quite right, whereas "are you going to back-patch this to v10?"
> lines up correctly in my head, but I don't hold that distinction
> very closely and either would work.

What's wrong with, "Are you going to back-patch this to 10?"

Bear in mind that this sentence first makes sense once we've got a new
branch for 11, gets more likely as we have 12 and 13, then drops,
after that, all the way to 0 when we hit 16, which by my calculation
should be in the 2020s.  Some of the people who will be our major
contributors then are in high school now, and will just be puzzled and
vaguely annoyed by references to the old system.

Now, when we're changing the visible version number, seems like the
time to break fully with the idea that our major version numbers have
two parts.  We'll still be referring, with decreasing frequency, to
9.6, 9.5, 9.4, etc., but there's good reason not to carry that idea
forward now that we're no longer doing it.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David,

* David Fetter (david@fetter.org) wrote:
> On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > > "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on
> > > > the lists.  I suspect the choice will be dependent on context and channel.
> > >
> > > Hmm, that seems like a workable answer as well, and one that's traceable
> > > to our past habits.
> >
> > For my 2c, I'd kind of prefer v10, but I could live with 10.x.
> >
> > Not sure that I have any real reason for that preference other than
> > 'v10' is slightly shorter and seems more 'right', to me.
>
> 10 is even shorter, and when we get to 15, it seems like it'll be
> pretty silly still to be referring to the 9.x series.
>
> > In other words, "are you going to back-patch this to 10.x?" doesn't
> > seem quite right, whereas "are you going to back-patch this to v10?"
> > lines up correctly in my head, but I don't hold that distinction
> > very closely and either would work.
>
> What's wrong with, "Are you going to back-patch this to 10?"

It can end up being ambiguous, as Tom already pointed out.

> Bear in mind that this sentence first makes sense once we've got a new
> branch for 11, gets more likely as we have 12 and 13, then drops,
> after that, all the way to 0 when we hit 16, which by my calculation
> should be in the 2020s.  Some of the people who will be our major
> contributors then are in high school now, and will just be puzzled and
> vaguely annoyed by references to the old system.

I don't see referring to a single-digit version number as 'v11' or 'v15'
instead of '15' to be some kind of reference to the "old system" but
rather a way of distinguishing a version or branch identifier from being
some other value.  This discussion about "v10" vs. "10.x" hasn't
actually got anything to do with the prior three-digit "9.4.x" or "9.4"
system but has everything to do with what we're going to say going
forward.

> Now, when we're changing the visible version number, seems like the
> time to break fully with the idea that our major version numbers have
> two parts.  We'll still be referring, with decreasing frequency, to
> 9.6, 9.5, 9.4, etc., but there's good reason not to carry that idea
> forward now that we're no longer doing it.

The notion of "10.x" doesn't refer to a two-digit major version, it
refers to a single-digit major version with multiple minor releases,
which we will certainly have, so I don't understand where you're coming
from here.

Thanks!

Stephen

On 08/01/2016 11:49 AM, Tom Lane wrote:
>
> 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?
>
>             


Somewhat related is how we name the git branches. It would help me from 
a buildfarm POV if we kept lexically them sortable, which could be done 
at least for the next 90 major releases :-) by adding an underscore 
after the REL piece, thus: REL_10_STABLE. I realise that's a way off, 
but it's worth bringing up while we're discussing the topic.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Somewhat related is how we name the git branches. It would help me from 
> a buildfarm POV if we kept lexically them sortable, which could be done 
> at least for the next 90 major releases :-) by adding an underscore 
> after the REL piece, thus: REL_10_STABLE. I realise that's a way off, 
> but it's worth bringing up while we're discussing the topic.

Hmm, sounds a bit C-locale-centric, but I have no objection to inserting
an underscore there if it seems helpful.

What I thought would be worth discussing is whether to continue using the
"_STABLE" suffix.  It seems rather like a noise word for our purposes.
OTOH, dropping it might be a headache for scripts that deal with branch
names --- any thoughts?
        regards, tom lane

On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Somewhat related is how we name the git branches. It would help me from
>> a buildfarm POV if we kept lexically them sortable, which could be done
>> at least for the next 90 major releases :-) by adding an underscore
>> after the REL piece, thus: REL_10_STABLE. I realise that's a way off,
>> but it's worth bringing up while we're discussing the topic.
>
> Hmm, sounds a bit C-locale-centric, but I have no objection to inserting
> an underscore there if it seems helpful.
>
> What I thought would be worth discussing is whether to continue using the
> "_STABLE" suffix.  It seems rather like a noise word for our purposes.
> OTOH, dropping it might be a headache for scripts that deal with branch
> names --- any thoughts?

I would have thought that REL10_STABLE is the best balance between
what we have now and the future numbering system.
-- 
Michael

Michael Paquier wrote:
> On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andrew Dunstan <andrew@dunslane.net> writes:
> >> Somewhat related is how we name the git branches. It would help me from
> >> a buildfarm POV if we kept lexically them sortable, which could be done
> >> at least for the next 90 major releases :-) by adding an underscore
> >> after the REL piece, thus: REL_10_STABLE. I realise that's a way off,
> >> but it's worth bringing up while we're discussing the topic.
> >
> > Hmm, sounds a bit C-locale-centric, but I have no objection to inserting
> > an underscore there if it seems helpful.
> >
> > What I thought would be worth discussing is whether to continue using the
> > "_STABLE" suffix.  It seems rather like a noise word for our purposes.
> > OTOH, dropping it might be a headache for scripts that deal with branch
> > names --- any thoughts?
> 
> I would have thought that REL10_STABLE is the best balance between
> what we have now and the future numbering system.

If we drop the STABLE then it's fairly easy to distinguish names from
the two-part majors era, and the one-part majors era (just check for
presence of the _STABLE suffix).  I don't see any value to the _STABLE
suffix, given the way we treat branches.

That said, I'm not opposed to REL_10 and so on.  In 89 years there will
be a problem with sorting REL_100 but I'm sure they can find a solution
then, if computers still need humans to write programs for them.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> That said, I'm not opposed to REL_10 and so on.  In 89 years there will
> be a problem with sorting REL_100 but I'm sure they can find a solution
> then, if computers still need humans to write programs for them.

It would be nice if there was a consistent way of referring to a
version regardless of how old it was.

There would be nothing stopping us from going back and adding tags for
existing versions. We could add REL_09_5 back to REL_06_5 if we wanted
to. Then we could easily refer to any version without special cases or
rules about pre-10 vs post-10. It would also give a convenient chance
to fix the inconsistencies in how some of the older branches were
tagged.

-- 
greg

Greg Stark <stark@mit.edu> writes:
> On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> That said, I'm not opposed to REL_10 and so on.  In 89 years there will
>> be a problem with sorting REL_100 but I'm sure they can find a solution
>> then, if computers still need humans to write programs for them.

> It would be nice if there was a consistent way of referring to a
> version regardless of how old it was.

> There would be nothing stopping us from going back and adding tags for
> existing versions.

The discussion here is about branches, not tags.  I don't know of any
way to have an alias for a branch (though I'm no git expert).

> It would also give a convenient chance
> to fix the inconsistencies in how some of the older branches were
> tagged.

I thought we'd pretty much done that cleanup during the cvs->git
conversion?
        regards, tom lane

On 8/1/16 9:10 PM, Alvaro Herrera wrote:
> I don't see any value to the _STABLE
> suffix, given the way we treat branches.

It would be nice to be able to tell easily from convention whether
something is a branch or a tag.

Anyway, this is a question for many months from now.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 8/1/16 11:49 AM, Tom Lane wrote:
> Somebody needs to come up with a patch implementing this changeover.

Here is such a patch.  It does not yet implement:

> (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.)

e.g., in psql, but that's a UI issue that can be sorted out.

One hiccup I found is that server_version_num is not sent to clients.
Instead, libpq assembles the numeric version number itself from the
string version, and it will fail if it sees only one number (e.g.,
10devel).  It will then set the version number to 0 for "unknown".
Client code such as psql and pg_dump is coded so that it will then fall
back to code for the oldest server version it happens to support (less
than 8.1 at times).  So in other words, old psql plus new server up
until production release will have many \d commands failing.  Once the
release becomes 10.0, it will work again.  (It will still think in terms
of three-component versions, but it won't make a difference in practice.)

Some possibilities to make this slightly better:

- Report server_version_num to clients, and use that.

- If libpq can't parse the version number, it should set it to its own
version number instead of 0.  Alternatively,

- If psql sees a server version number of 0, it should assume its own
version number.

- Similarly for pg_dump, although old pg_dump with new server is not
really supported anyway.


Apart from some UI issues, the attached patch passes check-world.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/1/16 9:10 PM, Alvaro Herrera wrote:
>> I don't see any value to the _STABLE
>> suffix, given the way we treat branches.

> It would be nice to be able to tell easily from convention whether
> something is a branch or a tag.

Well, the rule would be that "REL_xx" is a branch, "REL_xx_yy" is a
release tag.  Neither of these is confusable with old-style
branch or tag names.  The alternative seems to be saying that
"REL_xx_STABLE" is a branch while "REL_xx_yy" is a release tag.
That works but it doesn't seem to have all that much to recommend it;
unless there is code in the buildfarm or elsewhere that really wants
to see _STABLE in the branch names.

> Anyway, this is a question for many months from now.

True, but we might as well make the decisions now.
        regards, tom lane

On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I thought we'd pretty much done that cleanup during the cvs->git
> conversion?

I guess I'm talking about tags. I'm not clear on the distinction
between tags and branches names in git.

Prior to 8.0.0 we seem to have tagged the first release with a tag
that doesn't include _0 for the minor release and afterwards with one
that does:

REL2_0
REL6_1
REL6_2
REL6_4
REL7_0
REL7_1
REL7_2
REL7_3
REL7_4
REL8_0_0
REL8_1_0
...



-- 
greg

On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, the rule would be that "REL_xx" is a branch, "REL_xx_yy" is a
> release tag.  Neither of these is confusable with old-style
> branch or tag names.  The alternative seems to be saying that
> "REL_xx_STABLE" is a branch while "REL_xx_yy" is a release tag.
> That works but it doesn't seem to have all that much to recommend it;
> unless there is code in the buildfarm or elsewhere that really wants
> to see _STABLE in the branch names.

It would also be nice to have a tag or branch name for the development
branch. Right now git-describe --tags on a random revision between 9.4
and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
beta. It's really hard to tell what release the revision you're on is
actually between from that.

There's also a git feature I just noticed called "annotations". Tags
can be "annotated" with a commit message and then git describe will
only use those and skip other tags that are not annotated. Currently
we appear to have no annotated tags. (which confuses me because there
are clearly commit messages for the tags with logs like "Stamp
9.5alpha" c.f. f78329d594c2fe893f9174d5b3da7d3fbc6dd8b6)

It would be nice if git describe on a random revision between 9.4 and
9.5 always printed something like REL_09_05_DEV-* which indicated it
was some revision committed after 9.4 was branched and before 9.5.0
was released. (That would sort incorrectly so maybe some further tweak
is needed?)

-- 
greg

Greg Stark <stark@mit.edu> writes:
> On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I thought we'd pretty much done that cleanup during the cvs->git
>> conversion?

> I guess I'm talking about tags. I'm not clear on the distinction
> between tags and branches names in git.

> Prior to 8.0.0 we seem to have tagged the first release with a tag
> that doesn't include _0 for the minor release and afterwards with one
> that does:

> REL2_0
> REL6_1
> REL6_2
> REL6_4
> REL7_0
> REL7_1
> REL7_2
> REL7_3
> REL7_4
> REL8_0_0
> REL8_1_0

Ah.  Well, that's a reflection of what those releases were actually
called at the time: we did not start using ".0" on major releases
until the 8.0 branch.  Compare tarball names in
https://www.postgresql.org/ftp/source/v7.4/
https://www.postgresql.org/ftp/source/v8.0/

So we could go back and add tags like REL7_4_0 but it would be historical
revisionism.  Is there a particular reason to do it?  It seems like stuff
that far back is only of historical interest, so I'm kind of -1 on
corrupting the historical record with retroactive labels.

BTW, there are some missing tags back there, for instance no REL7_0_1.
I believe this is because we couldn't exactly identify which commit
corresponded to the published tarballs.  I'd be for filling in those gaps
if anyone can figure it out.
        regards, tom lane

Greg Stark <stark@mit.edu> writes:
> It would also be nice to have a tag or branch name for the development
> branch.

Uh, the branch name is "master".  I doubt we want to change that.
And you can't really have a tag on a branch, AFAIK --- a tag names
a specific commit and can't ever be moved.  I think the fundamental
difference between tags and branches is exactly that a branch is a
movable commit-pointer while a tag is fixed.

> Right now git-describe --tags on a random revision between 9.4
> and 9.5 will print something like REL9_4_BETA1-1973-g85c25fd or
> something like REL9_5_BETA2-33-g55a2cc8 if it happens to be after a
> beta. It's really hard to tell what release the revision you're on is
> actually between from that.

That command is kinda useless AFAICT :-(

> There's also a git feature I just noticed called "annotations". Tags
> can be "annotated" with a commit message and then git describe will
> only use those and skip other tags that are not annotated. Currently
> we appear to have no annotated tags. (which confuses me because there
> are clearly commit messages for the tags with logs like "Stamp
> 9.5alpha" c.f. f78329d594c2fe893f9174d5b3da7d3fbc6dd8b6)

Those commit messages are for the stamping commits, ie the ones that
put a new version number into configure.in and so on.  Tags get applied
to those commits after the fact, once we've verified that tarballs made
from those commits are publishable.  That is, the tags are meant to mark
which tree state the published tarballs were actually made from.  It has
happened that we've fixed something and re-wrapped after the stamping
commit, in which case the tag would be placed on a later commit.

I was just wondering whether it would be worth starting to use "git tag -a".
It doesn't seem to buy much, and if it would cause git describe to ignore
all non-annotated tags, I should think that that's a misfeature.

> It would be nice if git describe on a random revision between 9.4 and
> 9.5 always printed something like REL_09_05_DEV-* which indicated it
> was some revision committed after 9.4 was branched and before 9.5.0
> was released. (That would sort incorrectly so maybe some further tweak
> is needed?)

I think you need to file a feature request with the git folk.
        regards, tom lane

On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel).  It will then set the version number to 0 for "unknown".
> Client code such as psql and pg_dump is coded so that it will then fall
> back to code for the oldest server version it happens to support (less
> than 8.1 at times).  So in other words, old psql plus new server up
> until production release will have many \d commands failing.  Once the
> release becomes 10.0, it will work again.  (It will still think in terms
> of three-component versions, but it won't make a difference in practice.)

This pretty much sucks.  I suppose we could at least alleviate the
problem by back-patching some intelligence about the new scheme into
back-branches, but of course that will only help people if they
install newer minor releases.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> One hiccup I found is that server_version_num is not sent to clients.
>> Instead, libpq assembles the numeric version number itself from the
>> string version, and it will fail if it sees only one number (e.g.,
>> 10devel).  It will then set the version number to 0 for "unknown".

Ugh.

> This pretty much sucks.  I suppose we could at least alleviate the
> problem by back-patching some intelligence about the new scheme into
> back-branches, but of course that will only help people if they
> install newer minor releases.

Yeah.  I doubt there is much reason to assume that people would be
using, say, a 9.5.5 psql and a 9.5.3 libpq or vice versa.  Whatever
the current client behavior is is what people will see.

Having said that, this sort of problem is one reason we wanted to give
ourselves a full year to implement the new scheme.  If we put some
appropriate fix into the back branches *now*, there would be a fair
amount of daylight for that to spread into the field before any users
would be seeing v10 servers in practice.

So it seems like fixing libpq's parsing of server_version_num is
something we definitely want to fix ASAP in all back branches.
Is there anything else that's particularly bad?
        regards, tom lane

Craig Ringer <craig@2ndquadrant.com> writes:
> On 4 August 2016 at 02:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So it seems like fixing libpq's parsing of server_version_num is
>> something we definitely want to fix ASAP in all back branches.

> Well, this seems like a good time to make server_version_num GUC_REPORT as
> well...

To what end?  Existing versions of libpq wouldn't know about it, and new
versions of libpq couldn't rely on it to get reported by older servers,
so it'd still be the path of least resistance to examine server_version.
        regards, tom lane

Craig Ringer <craig@2ndquadrant.com> writes:
> On 4 August 2016 at 12:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Craig Ringer <craig@2ndquadrant.com> writes:
>>> Well, this seems like a good time to make server_version_num GUC_REPORT
>>> as well...

>> To what end?  Existing versions of libpq wouldn't know about it, and new
>> versions of libpq couldn't rely on it to get reported by older servers,
>> so it'd still be the path of least resistance to examine server_version.

> Because it's really silly that we don't,

Sorry, but I don't buy that.  I think sending both server_version and
server_version_num would be silly, and we're certainly not going to stop
sending server_version.
        regards, tom lane

Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes:
>> Sorry, but I don't buy that.  I think sending both server_version and
>> server_version_num would be silly, and we're certainly not going to stop
>> sending server_version.

> What is wrong with sending machine-readable value?

[ shrug... ]  What do you claim is not machine-readable about
server_version?
        regards, tom lane

On 8/3/16 1:20 PM, Tom Lane wrote:
> I was just wondering whether it would be worth starting to use "git tag -a".

One should always use annotated tags for public releases.  That way, the
tag is its own Git object that cannot be later moved around or easily
faked (modulo GPG signatures -- a whole different discussion).

Unannotated tags are more intended for private labels.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes:
>>> Sorry, but I don't buy that.  I think sending both server_version and
>>> server_version_num would be silly, and we're certainly not going to stop
>>> sending server_version.
>
>> What is wrong with sending machine-readable value?
>
> [ shrug... ]  What do you claim is not machine-readable about
> server_version?

Surely you can't have missed the connection between the issue at hand
and what Craig is talking about.  If libpq were using the
machine-readable version rather than PARSING A STRING, switching to a
two-part numbering scheme wouldn't force a compatibility break.  Every
driver that his independently implemented the PostgreSQL wire protocol
is going to have to be updated for this, if they're doing something
similar to libpq, and you're still asking why sending
server_version_num is potentially beneficial?

I think it's entirely reasonable to ask whether it's worth burdening
connection startup with a few extra bytes of essentially duplicative
information is a good idea on performance grounds, and I don't know
the answer to that question.  But pretending like it wouldn't help
anything when it would fix *the exact problem we are currently talking
about* is just sticking your head in the sand.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ shrug... ]  What do you claim is not machine-readable about
>> server_version?

> Surely you can't have missed the connection between the issue at hand
> and what Craig is talking about.  If libpq were using the
> machine-readable version rather than PARSING A STRING, switching to a
> two-part numbering scheme wouldn't force a compatibility break.

Well, yeah, this specific case would not have broken, because we
intentionally chose to maintain backwards compatibility of the
PG_VERSION_NUM data format.  But I think there's nothing much except
wishful thinking backing up the idea that starting to send
server_version_num now will prevent a bug in future.  If we ever do
change our version numbering scheme again, it would quite possibly
be in a way that breaks PG_VERSION_NUM as well.  A fairly obvious
potential reason to need to change something there is overflow of
the two-digit fields: clients relying on PG_VERSION_NUM would be
*more* at risk, not less so, than clients looking at a string.

In short: if we'd done it that way all along, it would've been nice.
But encouraging people to change horses now isn't really going to
make things better.  What is far more likely to happen, if we were
to do that, is that people will make clients that gratuitously fail
on old server versions because they didn't bother to support or test
for the case that the server doesn't send server_version_num.

You don't really want to encourage multiple ways of identifying which
software version you're dealing with.  That way madness lies.
        regards, tom lane

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/3/16 1:20 PM, Tom Lane wrote:
>> I was just wondering whether it would be worth starting to use "git tag -a".

> One should always use annotated tags for public releases.  That way, the
> tag is its own Git object that cannot be later moved around or easily
> faked (modulo GPG signatures -- a whole different discussion).

AFAIK, you can't really move around a plain tag either.  Certainly that's
why we go out of our way not to tag releases until we're certain we don't
need a re-wrap.
        regards, tom lane

On 08/01/2016 04:25 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Somewhat related is how we name the git branches. It would help me from
>> a buildfarm POV if we kept lexically them sortable, which could be done
>> at least for the next 90 major releases :-) by adding an underscore
>> after the REL piece, thus: REL_10_STABLE. I realise that's a way off,
>> but it's worth bringing up while we're discussing the topic.
> Hmm, sounds a bit C-locale-centric, but I have no objection to inserting
> an underscore there if it seems helpful.


Good. FTR I tested this with every locale on my system and the results 
were identical .


>
> What I thought would be worth discussing is whether to continue using the
> "_STABLE" suffix.  It seems rather like a noise word for our purposes.
> OTOH, dropping it might be a headache for scripts that deal with branch
> names --- any thoughts?
>
>             


Just from the buildfarm POV it poses no difficulties.

cheers

andrew

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel).  It will then set the version number to 0 for "unknown".

Per discussion, I applied and back-patched the libpq/fe-exec.c part
of this, so that back-branch clients will have a decent chance of
understanding the new server_version format by the time it hits the field.

In a quick look around, it seemed like we might also want to fix and
back-patch the server version printing logic in psql's
connection_warnings() function.  However that would involve touching
a translatable string so I thought it best not to do it just before
back-branch releases.
        regards, tom lane

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 8/1/16 11:49 AM, Tom Lane wrote:
>> Somebody needs to come up with a patch implementing this changeover.

> Here is such a patch.  It does not yet implement:

I've pushed this with minor additional twiddling.  We can work on the
"UI issues" you mentioned at leisure.  One that I noted is that psql's
version-mismatch-warning messages aren't two-part-version aware, and
will print "10.0" where they should say "10".  Probably that fix should
get back-patched, so that older psql branches will do the right thing
if possible.

I tried to fix the MSVC build to work, but I've not tested it and
am waiting to see what the buildfarm says.
        regards, tom lane

I wrote:
> I've pushed this with minor additional twiddling.  We can work on the
> "UI issues" you mentioned at leisure.  One that I noted is that psql's
> version-mismatch-warning messages aren't two-part-version aware, and
> will print "10.0" where they should say "10".  Probably that fix should
> get back-patched, so that older psql branches will do the right thing
> if possible.

Attached is a WIP patch for that.  I've only fixed psql/command.c
so far, but I put the support logic into fe_utils since we're going
to need it in some other places too (pg_dump at least).  Any objections
to this general approach?

            regards, tom lane

diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 9c0af4e..4aaf657 100644
*** a/src/bin/psql/command.c
--- b/src/bin/psql/command.c
*************** exec_command(const char *cmd,
*** 635,642 ****

          if (pset.sversion < 80400)
          {
!             psql_error("The server (version %d.%d) does not support editing function source.\n",
!                        pset.sversion / 10000, (pset.sversion / 100) % 100);
              status = PSQL_CMD_ERROR;
          }
          else if (!query_buf)
--- 635,645 ----

          if (pset.sversion < 80400)
          {
!             char        sverbuf[32];
!
!             psql_error("The server (version %s) does not support editing function source.\n",
!                        formatPGVersionNumber(pset.sversion, false,
!                                              sverbuf, sizeof(sverbuf)));
              status = PSQL_CMD_ERROR;
          }
          else if (!query_buf)
*************** exec_command(const char *cmd,
*** 731,738 ****

          if (pset.sversion < 70400)
          {
!             psql_error("The server (version %d.%d) does not support editing view definitions.\n",
!                        pset.sversion / 10000, (pset.sversion / 100) % 100);
              status = PSQL_CMD_ERROR;
          }
          else if (!query_buf)
--- 734,744 ----

          if (pset.sversion < 70400)
          {
!             char        sverbuf[32];
!
!             psql_error("The server (version %s) does not support editing view definitions.\n",
!                        formatPGVersionNumber(pset.sversion, false,
!                                              sverbuf, sizeof(sverbuf)));
              status = PSQL_CMD_ERROR;
          }
          else if (!query_buf)
*************** exec_command(const char *cmd,
*** 1362,1369 ****
                                        OT_WHOLE_LINE, NULL, true);
          if (pset.sversion < 80400)
          {
!             psql_error("The server (version %d.%d) does not support showing function source.\n",
!                        pset.sversion / 10000, (pset.sversion / 100) % 100);
              status = PSQL_CMD_ERROR;
          }
          else if (!func)
--- 1368,1378 ----
                                        OT_WHOLE_LINE, NULL, true);
          if (pset.sversion < 80400)
          {
!             char        sverbuf[32];
!
!             psql_error("The server (version %s) does not support showing function source.\n",
!                        formatPGVersionNumber(pset.sversion, false,
!                                              sverbuf, sizeof(sverbuf)));
              status = PSQL_CMD_ERROR;
          }
          else if (!func)
*************** exec_command(const char *cmd,
*** 1441,1448 ****
                                        OT_WHOLE_LINE, NULL, true);
          if (pset.sversion < 70400)
          {
!             psql_error("The server (version %d.%d) does not support showing view definitions.\n",
!                        pset.sversion / 10000, (pset.sversion / 100) % 100);
              status = PSQL_CMD_ERROR;
          }
          else if (!view)
--- 1450,1460 ----
                                        OT_WHOLE_LINE, NULL, true);
          if (pset.sversion < 70400)
          {
!             char        sverbuf[32];
!
!             psql_error("The server (version %s) does not support showing view definitions.\n",
!                        formatPGVersionNumber(pset.sversion, false,
!                                              sverbuf, sizeof(sverbuf)));
              status = PSQL_CMD_ERROR;
          }
          else if (!view)
*************** connection_warnings(bool in_startup)
*** 2014,2035 ****
      if (!pset.quiet && !pset.notty)
      {
          int            client_ver = PG_VERSION_NUM;

          if (pset.sversion != client_ver)
          {
              const char *server_version;
-             char        server_ver_str[16];

              /* Try to get full text form, might include "devel" etc */
              server_version = PQparameterStatus(pset.db, "server_version");
              if (!server_version)
              {
!                 snprintf(server_ver_str, sizeof(server_ver_str),
!                          "%d.%d.%d",
!                          pset.sversion / 10000,
!                          (pset.sversion / 100) % 100,
!                          pset.sversion % 100);
!                 server_version = server_ver_str;
              }

              printf(_("%s (%s, server %s)\n"),
--- 2026,2046 ----
      if (!pset.quiet && !pset.notty)
      {
          int            client_ver = PG_VERSION_NUM;
+         char        cverbuf[32];
+         char        sverbuf[32];

          if (pset.sversion != client_ver)
          {
              const char *server_version;

              /* Try to get full text form, might include "devel" etc */
              server_version = PQparameterStatus(pset.db, "server_version");
+             /* Otherwise fall back on pset.sversion */
              if (!server_version)
              {
!                 formatPGVersionNumber(pset.sversion, true,
!                                       sverbuf, sizeof(sverbuf));
!                 server_version = sverbuf;
              }

              printf(_("%s (%s, server %s)\n"),
*************** connection_warnings(bool in_startup)
*** 2040,2049 ****
              printf("%s (%s)\n", pset.progname, PG_VERSION);

          if (pset.sversion / 100 > client_ver / 100)
!             printf(_("WARNING: %s major version %d.%d, server major version %d.%d.\n"
                       "         Some psql features might not work.\n"),
!                  pset.progname, client_ver / 10000, (client_ver / 100) % 100,
!                    pset.sversion / 10000, (pset.sversion / 100) % 100);

  #ifdef WIN32
          checkWin32Codepage();
--- 2051,2063 ----
              printf("%s (%s)\n", pset.progname, PG_VERSION);

          if (pset.sversion / 100 > client_ver / 100)
!             printf(_("WARNING: %s major version %s, server major version %s.\n"
                       "         Some psql features might not work.\n"),
!                    pset.progname,
!                    formatPGVersionNumber(client_ver, false,
!                                          cverbuf, sizeof(cverbuf)),
!                    formatPGVersionNumber(pset.sversion, false,
!                                          sverbuf, sizeof(sverbuf)));

  #ifdef WIN32
          checkWin32Codepage();
diff --git a/src/fe_utils/string_utils.c b/src/fe_utils/string_utils.c
index f986dbc..2c566b1 100644
*** a/src/fe_utils/string_utils.c
--- b/src/fe_utils/string_utils.c
*************** fmtQualifiedId(int remoteVersion, const
*** 169,174 ****
--- 169,212 ----


  /*
+  * Format a Postgres version number (in the PG_VERSION_NUM integer format
+  * returned by PQserverVersion()) as a string.  This exists mainly to
+  * encapsulate knowledge about two-part vs. three-part version numbers.
+  *
+  * For re-entrancy, caller must supply the buffer the string is put in.
+  * Recommended size of the buffer is 32 bytes.
+  *
+  * Returns address of 'buf', as a notational convenience.
+  */
+ char *
+ formatPGVersionNumber(int version_number, bool include_minor,
+                       char *buf, size_t buflen)
+ {
+     if (version_number >= 100000)
+     {
+         /* New two-part style */
+         if (include_minor)
+             snprintf(buf, buflen, "%d.%d", version_number / 10000,
+                      version_number % 10000);
+         else
+             snprintf(buf, buflen, "%d", version_number / 10000);
+     }
+     else
+     {
+         /* Old three-part style */
+         if (include_minor)
+             snprintf(buf, buflen, "%d.%d.%d", version_number / 10000,
+                      (version_number / 100) % 100,
+                      version_number % 100);
+         else
+             snprintf(buf, buflen, "%d.%d", version_number / 10000,
+                      (version_number / 100) % 100);
+     }
+     return buf;
+ }
+
+
+ /*
   * Convert a string value to an SQL string literal and append it to
   * the given buffer.  We assume the specified client_encoding and
   * standard_conforming_strings settings.
diff --git a/src/include/fe_utils/string_utils.h b/src/include/fe_utils/string_utils.h
index 7bbed36..452ffc0 100644
*** a/src/include/fe_utils/string_utils.h
--- b/src/include/fe_utils/string_utils.h
*************** extern const char *fmtId(const char *ide
*** 30,35 ****
--- 30,38 ----
  extern const char *fmtQualifiedId(int remoteVersion,
                 const char *schema, const char *id);

+ extern char *formatPGVersionNumber(int version_number, bool include_minor,
+                       char *buf, size_t buflen);
+
  extern void appendStringLiteral(PQExpBuffer buf, const char *str,
                      int encoding, bool std_strings);
  extern void appendStringLiteralConn(PQExpBuffer buf, const char *str,