Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers