>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.
Sincerely,
Joshua D. Drake
>cheers
>
>andrew
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.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@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL