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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
