Re: 10.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Josh berkus <josh(at)agliodbs(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Thom Brown <thom(at)linux(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 10.0
Date: 2016-05-13 20:02:01
Message-ID: 16377.1463169721@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

  • Re: 10.0 at 2016-05-13 19:41:00 from Andres Freund

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2016-05-13 20:03:32 Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Previous Message Andres Freund 2016-05-13 19:48:34 Re: Perf Benchmarking and regression.