On Mon, 2007-10-22 at 12:37 -0700, Josh Berkus wrote: > Simon, > > > We can issue a provisional date. We could also say "at least 6 months > > after release date of 8.3". I'm sure there's other options too. > > I'm going to suggest 4 months after 8.3. 8.3 was supposed to be a *short* > release so that we could move our calendar around. HOT and some of the > other unexpected massive patches prevented that. Again, we have enough in > the "deferred for 8.4" queue that if we finished up only that it would > qualify as a release. > > So my thought is, shoot for a short release so that we can get away from > summer consolidations and December releases, and extend the cycle if > someone dumps another 50,000 lines of attractive patches on us. > > In fact, I could see doing a "no-catalog-changes, no major patches we don't > already know about, 6-month release". It would reset our cycle and get > PL/proxy, DSM, clustered indexes, etc. out the door. It could mean > turning away patches which look attractive, though, so the whole community > has to be into this.
Those dates shocked me when I first read them, but I feel we need to have an aggressive release schedule, so I'll support that. I hope that the single most important criterion for deciding the release date(s) is How to Get the Most Good New Features into Postgres. That should be more important than other considerations, but I guess in the end, turning patches away may be the only way to ever do a release. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
