Re: EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 12:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ man, this thread has totally outlived its title, could we change that?
>  I'll start with this subtopic ]
>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> In fact, I've been wondering if we shouldn't consider extending the
>> support window for 8.2 past the currently-planned December 2011.
>> There seem to be quite a lot of people running that release precisely
>> because the casting changes in 8.3 were so painful, and I think the
>> incremental effort on our part to extend support for another year
>> would be reasonably small.  I guess the brunt of the work would
>> actually fall on the packagers.  It looks like we've done 5 point
>> releases of 8.2.x in the last year, so presumably if we did decide to
>> extend the EOL date by a year or so that's about how much incremental
>> effort would be needed.
>
> I agree that the incremental effort would not be so large, but what
> makes you think that the situation will change given another year?
> My expectation is that'd just mean people will do nothing about
> migrating for a year longer.
>
> More generally: it took a lot of argument to establish the current EOL
> policy, and bending it the first time anyone feels any actual pain
> will pretty much destroy the whole concept.

I don't think that's quite a fair description of the proposal. I
don't think that having a general policy about EOL should preclude us
from making exceptions when there is some particularly compelling
reason to do so, and "it's particularly difficult to upgrade to
release X+1" seems to me to be something that might merit a bit of
consideration in that area. It is hard to imagine that 8.3, 8.4, 9.0,
or 9.1 could justify special treatment on similar grounds, nor did
7.4, 8.0, or 8.1, which we recently retired under this policy.

However, I can see that I'm way, way in the minority on this one, so
never mind! It was just a thought...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company