Re: Version Numbering - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Version Numbering
Date
Msg-id AANLkTikcN0vb+FFtAm8J6W3+Ts1AfXDbh9LOHg0-BGMA@mail.gmail.com
Whole thread Raw
In response to Re: Version Numbering  (Greg Stark <gsstark@mit.edu>)
Responses Re: Version Numbering
List pgsql-hackers
>> Or at least to RTFM if they don't.

> If this were true, this thread wouldn't be as long as it is, nor would
> our mailing lists be anywhere near as busy as they are.

This thread is as long as it is principally because people generally
bikeshed about things that are easy to understand, and are fun to have
an opinion about.

> Frankly I think we've been bumping version numbers too often. It's a
> consequence of the insane pace of development we've had. Adding PITR
> in 8.0 was a pretty major step and hot standby in 9.0 will be big too.
> But we should be limiting the first digit for Perl 6 scale changes,
> not just features that are really really cool.

While I generally agree with your views about versioning conventions,
if we did that, we'd probably never bump the major version number. As
far as I'm aware, Postgres has never had such radical changes in a
single release, that broke compatibility to such an extent. Also,
while we aren't subject to the same commercial pressures as the
proprietary vendors, I don't think that we can afford to not have our
versioning conventions informed by marketing concerns to any extent.
We changed 8.5 to 9.0 explicitly because doing so was good marketing,
and also because of HS/SR (plus we wanted to hint at the fact that 9.0
might not be the most stable release we've had), and I'm inclined to
agree with that.


-- 
Regards,
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Replacing the pg_get_expr security hack with a datatype solution
Next
From: Robert Haas
Date:
Subject: Re: Replacing the pg_get_expr security hack with a datatype solution