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!).



Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to