Josh Berkus wrote:
I'll also say: if we can't make time-based releases work, we're probably dead as a project. MySQL and Ingres both tried feature-based releases, and look where they are now.
I think you're engaging in a bit of 'post hoc ergo propter hoc' reasoning here.
In any case, I think it's a false dichotomy. We always seem to treat this as an all or nothing deal. But there is no reason that we must. We could easily decide that one or two features were critical for the release and everything else would have to make the time cut. For this release those features would obviously be HS and SR. Obviously we could could at some stage decide to cut our losses and run, as we did last release (eventually). But I think that the idea that we should never at least have a stated goal to have certain features in a given release is a bit silly.
If you think we could put out this coming release without having HS + SR, and not do significant damage to the project, I can only say I profoundly disagree.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
