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