From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EOL for 7.4? |
Date: | 2009-11-03 15:28:24 |
Message-ID: | 9837222c0911030728r6fc558deh1ba472a9b29febce@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2009/11/3 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
>
> Robert Haas wrote:
>>
>> We had a discussion back in July about our maintenance policy and the
>> upshot of that discussion was that there were relatively few
>> objections to dropping support for 7.4 - I believe Andrew Dunstan was
>> the only one who spoke against it, and it wasn't clear how strenuous
>> his objections were - but there were objections even to setting an
>> end-of-life date for any subsequent release. However, we never really
>> took any action based on that conversation. Maybe it's time?
>>
>
> I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-)
>
> What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of "PostgreSQL release version n.n. will reach the end of its maintenance life on yyyy-mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version."
Didn't we discuss EOLing based on <number of previous versions>? As in
if we now announced that 7.4 would EOL when we release 8.5?
(Though based on previous track record, that means it really should've
been EOLed when we released 8.4, I guess)
>> We are also very close to six years from the original release, if
>> that's a magic number for anyone.
>>
>>
>
>
> Actually, I think it's a pretty good lifetime for a release. Many users don't want to migrate as soon as a new version comes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating more than once every few years - five would be a good number here. (This has nothing to do with whether or not we have in place upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) So allowing for those two things, six years is an excellent lifetime. And 7.4 has been pretty darn robust, it should be noted.
Yeah, if one version has to stick around for a long time, 7.4 was a
good choice for it :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-11-03 15:45:41 | function result typmod support, param typmod support |
Previous Message | Heikki Linnakangas | 2009-11-03 15:06:45 | Re: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale) |