Re: 10.0

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Josh berkus <josh@agliodbs.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, David Fetter <david@fetter.org>, Thom Brown <thom@linux.com>, Dave Page <dpage@pgadmin.org>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-05-13T20:02:01Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I'm in favor of doing something more radical than just stripping one
> digit off. We've tried (and only partially failed) to educate users that
> $major.$minor updates are the big ones; if we change that to essentially
> be $major.$micro, we'll have people not updating and such.

> So I'd rather go with 2016.01v0 or something.

Meh.  We could go with using the year of release as the major version;
that wouldn't be functionally different from what I suggested.  But
I don't want to invent some whole new notation.  That would break
version-comparison scripts for no good reason.  (As an ex-packager for
Red Hat, I know that people who invent their very own version notations
are cordially hated by all distros everywhere.  Let's stick to decimal
numbers with dots between, please.)

Although year-of-release would definitely have the advantage of making
it clear to everybody that Something Changed, I think it would still
be confusing over time.  "Why are you releasing 2017.6 in 2019?"
This is basically the same reason we got rid of the "Postgres95" name,
I believe, though I wasn't around at the time.  There's also the issue
I mentioned upthread that it becomes problematic if a release slips into
January.

My feeling is that going from 9 to 10 will in itself be a pretty good
boundary marker, in a way that wouldn't apply if we were trying to
introduce this scheme starting with 9 or 11.  So this is an ideal
opportunity to get it done.

			regards, tom lane