Message-ID: <3FB97CBC.8030900@commandprompt.com>
Date: Mon, 17 Nov 2003 17:58:20 -0800
From: "Joshua D. Drake" <jd@commandprompt.com>
Organization: Command Prompt, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.5) Gecko/20031014 Thunderbird/0.3
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Neil Conway <neilc@samurai.com>,
	PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Release cycle length
References: <Pine.LNX.4.44.0311180215410.639-100000@peter.localdomain>
In-Reply-To: <Pine.LNX.4.44.0311180215410.639-100000@peter.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

   Personally I am for long release cycles, at least for major releases. 
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.

   People are running their companies and lives off of PostgreSQL, they 
should
be able to rely on a specific feature set, and support from the community
for longer.

Sincerely,

Joshua Drake


Peter Eisentraut wrote:

>Neil Conway writes:
>
>  
>
>>Peter Eisentraut <peter_e@gmx.net> writes:
>>    
>>
>>>The time from release 7.3 to release 7.4 was 355 days, an all-time
>>>high.  We really need to shorten that.
>>>      
>>>
>>Why is that?
>>    
>>
>
>First, if you develop something today, the first time users would
>realistically get a hand at it would be January 2005.  Do you want that?
>Don't you want people to use your code?  We fix problems, but people must
>wait a year for the fix?
>
>Second, the longer a release cycle, the more problems amass.  People just
>forget what they were doing in the beginning, no one is around to fix the
>problems introduced earlier, no one remembers anything when it comes time
>to write release notes.  The longer you develop, the more parallel efforts
>are underway, and it becomes impossible to synchronize them to a release
>date.  People are not encouraged to provide small, well-thought-out,
>modular improvements.  Instead, they break everything open and worry about
>it later.  At the end, it's always a rush to close these holes.
>
>Altogether, it's a loss for both developers and users.
>
>  
>

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org