On 14/05/16 09:31, David G. Johnston wrote:
On Friday, May 13, 2016, Tom Lane <t...@sss.pgh.pa.us
<mailto:t...@sss.pgh.pa.us>> wrote:
Robert Haas <robertmh...@gmail.com <javascript:;>> writes:
> On Fri, May 13, 2016 at 2:49 PM, Tom Lane <t...@sss.pgh.pa.us
<javascript:;>> wrote:
> If we don't want to stick with the current practice of debating when
> to bump the same digit, then let's agree that 10.0 will follow
9.6 and
> after that we'll bump the first digit after X.4, as we did with 7.X
> and 8.X.
It was absolute, utter chance that the 7.x and 8.x series both ended
with .4. I see no reason to turn that into some kind of standard,
especially when it didn't work like that for 6.x or 9.x.
The underlying premise, for me, of choosing .4 or .5 was that
presently we discontinue support after 5 years/releases. A new .0
would come out just as we discontinue the previous .0
As an added idea, if switching to major.patch, would be to make 10.0.x
but then go to 11.x. Though that's somewhat easier cognitively it
would probably be harder for developers that just ripping off the bandaid.
David J.
I think the idea of incrementing the first digit when ever the last
major version reaches EOL, is probably the best compromise. If that was
adopted, then people could plan changes that triggered major breakage in
established usage accordingly.
I like the version 'x.y.z' approach, where 'z' mostly means bug fixes
and minor tweaks, 'y' has more significant enhancements, and 'x' may
mean major breakages. Lets not go down the Mozilla version inflation route.
For now, probably best if we have 9.5.n, 9.6.n, 10.0.n (where obviously
n starts at zero for each series!).
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
