Re: EOL for 7.4?

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/

In response to

Responses

Browse pgsql-hackers by date

  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)