Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

Peter Eisentraut 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

Re: [HACKERS] New version numbering practices

Peter Eisentraut 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

Re: [HACKERS] New version numbering practices

On 5 August 2016 at 04:31, Tom Lane wrote: > 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

Re: [HACKERS] New version numbering practices

On 08/01/2016 04:25 PM, Tom Lane wrote: Andrew Dunstan 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

Re: [HACKERS] New version numbering practices

Peter Eisentraut 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

Re: [HACKERS] New version numbering practices

Robert Haas writes: > On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane 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

Re: [HACKERS] New version numbering practices

On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane wrote: > Vladimir Sitnikov 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

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

Tom Lane : > [ shrug... ] What do you claim is not machine-readable about > server_version? > 0) server_version needs a dance to parse. For instance, recent "Stamp version 10devel" patch did touch "server_version" parsing in fe-exec.c:

Re: [HACKERS] New version numbering practices

Vladimir Sitnikov 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...

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

Craig Ringer writes: > On 4 August 2016 at 12:45, Tom Lane wrote: >> Craig Ringer writes: >>> Well, this seems like a good time to make server_version_num GUC_REPORT >>> as well... >> To what end? Existing versions of libpq

Re: [HACKERS] New version numbering practices

On 4 August 2016 at 12:45, Tom Lane wrote: > Craig Ringer writes: > > On 4 August 2016 at 02:15, Tom Lane wrote: > >> So it seems like fixing libpq's parsing of server_version_num is > >> something we definitely want to fix ASAP in

Re: [HACKERS] New version numbering practices

Craig Ringer writes: > On 4 August 2016 at 02:15, Tom Lane 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

Re: [HACKERS] New version numbering practices

On 4 August 2016 at 02:15, Tom Lane wrote: > Robert Haas writes: > > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut > > wrote: > >> One hiccup I found is that server_version_num is not sent to clients. > >>

Re: [HACKERS] New version numbering practices

Robert Haas writes: > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut > 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

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut 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

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 1:20 PM, Tom Lane wrote: > Greg Stark writes: > > 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

Re: [HACKERS] New version numbering practices

Greg Stark 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

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 5:27 PM, Tom Lane 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

Re: [HACKERS] New version numbering practices

On Wed, Aug 3, 2016 at 12:51 PM, Greg Stark wrote: > On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane 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 >

Re: [HACKERS] New version numbering practices

Greg Stark writes: > On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane 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.

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 2:57 PM, Tom Lane 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

Re: [HACKERS] New version numbering practices

Peter Eisentraut 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,

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

Greg Stark writes: > On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera > 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

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 2:10 AM, Alvaro Herrera 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.

Re: [HACKERS] New version numbering practices

Michael Paquier wrote: > On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote: > > Andrew Dunstan 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 >

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote: > Andrew Dunstan 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

Re: [HACKERS] New version numbering practices

Andrew Dunstan 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:

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

David, * David Fetter (da...@fetter.org) wrote: > On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > "David G. Johnston" writes: > > > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly

Re: [HACKERS] New version numbering practices

On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > "David G. Johnston" 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

Re: [HACKERS] New version numbering practices

* Tom Lane (t...@sss.pgh.pa.us) wrote: > "David G. Johnston" 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

Re: [HACKERS] New version numbering practices

"David G. Johnston" 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

Re: [HACKERS] New version numbering practices

On Mon, Aug 1, 2016 at 1:41 PM, Tom Lane wrote: > 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. ​I thought that was just (and

Re: [HACKERS] New version numbering practices

David Fetter 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

Re: [HACKERS] New version numbering practices

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

Re: [HACKERS] New version numbering practices

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-ea0f5ace4...@2ndquadrant.com > the decision has been taken to simplify our user-facing version numbering > system to be a two-component number. Since