Re: 10.0

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

In response to

  • Re: 10.0 at 2016-05-15 03:26:10 from Jeff Janes

Responses

  • Re: 10.0 at 2016-05-16 17:59:04 from Jeff Janes

Browse pgsql-hackers by date

  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