Skip site navigation (1) Skip section navigation (2)

Re: Development schedule

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgman(at)candle(dot)pha(dot)pa(dot)us, tgl(at)sss(dot)pgh(dot)pa(dot)us,scrappy(at)postgresql(dot)org, josh(at)agliodbs(dot)com,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Development schedule
Date: 2005-02-26 18:47:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>YES! Yes yes yes! I try to plan my time, and the feature freeze data is very
>important in that planning.

This is also important for people considering sponsoring developers.

>Also, regardless of the issues Tom raised, 18 months is too long a release
>cycle, IMNSHO. If you do that and you take the time from feature freeze of
>release n to release date of release n+1, a developer could wait 2 years
>from the date of submission to see his/her feature in a release. 2 years is
>an eternity in this game. Just my $0.02 worth.
I think it depends on the level of features being worked on. Look
at how long there is between Oracle major releases or **GASP** Mysql?

I think it is silly to have to wait 18 months for a new release
of say plPgsql of plPerl, new functions or maybe a new group by
capability... This should be able to be in . releases.

However... PITR, Savepoints? Those are major coding efforts. It
makes sense that they would take that long.


Joshua D. Drake

>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com -
PostgreSQL Replicator -- production quality replication for PostgreSQL

Attachment: jd.vcf
Description: text/x-vcard (285 bytes)

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2005-02-26 19:02:28
Subject: Re: idea for concurrent seqscans
Previous:From: Jim C. NasbyDate: 2005-02-26 16:16:27
Subject: Re: idea for concurrent seqscans

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group