From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Greg Sabino Mullane <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 10.0 |
Date: | 2016-05-15 03:26:10 |
Message-ID: | CAMkU=1xzMwrEs3Kz7OqfNdFxtPSP_DYJqs_aaxktarJcnST_-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane <greg(at)turnstep(dot)com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> Wasn't there some controversy about switching to major.minor versioning
>> this in -advocacy?
>>
>> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5f78@biglumber.com
>
> I proposed in that thread that we always increment the first number,
> never increment the second number, and increment the third exactly as we do
> now for bugfix releases.
I like this idea, roughly in line with SemVer.
There are lots of improvement which get done to in-memory data
structures that wouldn't require a pg_dump/pg_upgrade, which could in
principle be ported into prior major versions if we had the resources
(reviewing, testing, packaging) to do it, with an increase in the
middle number. Maybe we will never find the resources to do that, but
why should that assumption get baked into the numbering scheme?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-05-15 03:37:53 | Re: 10.0 |
Previous Message | Tom Lane | 2016-05-15 02:59:55 | Re: 10.0 |