Having a good "hard copy" (not having to search mailing list archives) of release dates would be really nice, not just for developers, but users too. Even if they are subject to change without notice.
I think Mozilla has a great concept with there Milestone Schedule, the gray table at: http://www.mozilla.org/roadmap.html#milestone-schedule. I'm sure having just a small table like what Mozilla uses on the PostgreSQL developers page would work wonders to eliminate much of the confusion in the future. On Tue, 2004-06-01 at 13:26 -0400, Andrew Dunstan wrote: > Marc G. Fournier wrote: > > > On Tue, 1 Jun 2004, Andrew Dunstan wrote: > > > >> Marc G. Fournier wrote: > >> > >>> > >>> Just so that everyone is aware, we are going to push the freeze date > >>> for 7.5 to July 1st. > >>> > >>> Although we feel that there are enough improvements and features > >>> already in place for 7.5, Tom's felt that if we gave it that extra > >>> month, we could also have PITR in place for 7.5 ... > >>> > >>> If anyone is working on other features that they feel can be > >>> polished off before the July 1st deadline, we would be most happy to > >>> incorporate those as well, but do recommend submitting patches for > >>> review *sooner*, rather then later, so that any recommended > >>> corrections can be addressed before teh deadline. > >>> > >> > >> I welcome this, as I always thought June 1 was too soon. However, I > >> think that the process by which the date was eventually arrived at > >> was unfortunate. > >> > >> I would modestly suggest that there should be a minimum period of > >> notice of a feature freeze - 6 weeks or 2 months seems about right to > >> me, given the > > > > > > Oh, you mean the original freeze date that was set at the start of the > > dev cycle 6 months ago? > > > > I am far from being the only person to whom this was less than clear. I > also know that when I discussed this with one or two members of the core > team *they* were not clear about it either. > > Maybe I missed something in an email somewhere ... > > In any case, I think a target date should be set at the beginning of a > dev cycle and a hard date should be set closer to the end of the cycle. > Trying to adhere rigidly to a date set nine or twelve months previously > doesn't strike me as good practice. > > cheers > > andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Mike Benoit <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
