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

Reply via email to