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 <[EMAIL PROTECTED]> writes:
The time from release 7.3 to release 7.4 was 355 days, an all-timeWhy is that?
high. We really need to shorten 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 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
