From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 10.0 |
Date: | 2016-05-15 03:37:53 |
Message-ID: | 4976.1463283473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> 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?
If we were to do that today, it'd just be an increase in the minor number.
I don't see why we'd need to change that approach. The real blocking
factors there are about manpower and stability of the resulting code, not
about whether you need some special version numbering to describe it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-05-15 06:02:15 | Re: Losing memory references - SRF + SPI |
Previous Message | Jeff Janes | 2016-05-15 03:26:10 | Re: 10.0 |