On Feb 11, 2008, at 9:33 AM, Ivan Sergio Borgonovo wrote:
> On Mon, 11 Feb 2008 15:36:21 +0100
> Magnus Hagander <magnus@hagander.net> wrote:
>> http://www.postgresql.org/support/security
>>
>> that's probably the best one you can find. Or that in combination
>> with the news archive (http://www.postgresql.org/about/newsarchive)
>
> Really... without making it too formal as a developer I'd appreciate
> a rough schedule a page where you would say something like:
>
> - we expect our next minor release will come out in X months
> - we expect our major release will come out in Y months
> - EOL of release A for platform B is planned around date Z
>
> Even with a disclaimer with a very bland commitment to the release
> schedule it could help developers to build up their own schedule and
> support list too and give some hook for advocacy as well.
The problem with that is that as a volunteer-run project, dates can
be off by a mile. Less than a year ago the plan was to release 8.3 is
August-September 2007. Instead it was released a week or two ago.
IIRC, the decision to end support for a version is determined in
large part by how hard it would be to back-patch something. If a bug
was found that dated back to 7.4 but was very difficult to fix in 7.4
I bet you'd see 7.4 get EOL'd unless someone wanted to pay to back-
patch it.
I think the closest thing to a policy you'll find is a discussion
from a year or two ago where the consensus was that we should
endeavor to support a version for at least 2 years after it's
replacement comes out (ie: 8.2 should be supported for at least 2
years after we released 8.3).
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
