Re: 10.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 10.0
Date
Msg-id 4976.1463283473@sss.pgh.pa.us
Whole thread Raw
In response to Re: 10.0  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: 10.0  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.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



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: 10.0
Next
From: Michael Paquier
Date:
Subject: Re: Losing memory references - SRF + SPI