New version numbering practices

On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote:

As Peter mentioned in
/messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Aug 1, 2016 at 1:41 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 maybe some instances were) humor regarding
the general indecisiveness on the issue.​

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.

​I think this dynamic will sort itself out.
​
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.

David J.

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers