Re: Release planning (was: Re: Status report)

On Wed, 2004-07-14 at 21:02, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > The big problem that I see with how this feature freeze/beta/release has
> > gone down is that we have *alot* of big items that are/were being worked
> > on (ARC, BGWriter, auto_vacuum, PITR, Nested Xacts), and only so much man
> > power at the reviewer stage ... we *should* have frozen it all on June
> > 1st, got the ready features out the door and released, and then
> > concentrated on getting the "almost ready, but not quite" features into
> > the next release as quickly as possible ...
> >
> > Hindsight is 20-20 ... maybe next time we'll learn from it?
>
> True, 20-20. One thing is that you can't schedule assuming full
> knowledge of the future, of course. For example, on May 1, I thought by
> June 1 PITR and NT would be done, and that Win32 and tablespaces
> wouldn't. What actually happened is that tablespaces made the deadline
> (with June adjustments), NT is in but needs more work, and Win32 is
> better off now than I thought it would be. And we don't know if PITR is
> ready or not because we haven't studied it enough.
>

I see a couple of issues:
- new releases of PostgreSQL require a full initdb. There is little
upgrade support as there is with other products. (Not complaining..)
- commercial products release around every 18 months...customers do NOT
want this to be any quicker...more disruptive upgrades, plus marketing
takes time to organise. I have customers that upgrade regularly every 3+
years (!), and take longer term strategy into consideration.
- commercial issues often cause products to be delayed....MS is said to
be late delivering Yukon....marketing-led companies often delay waiting
for the right feature set....saled-led companies never do. Delivering
early as Oracle often does mean that the received wisdom is never
upgrade to a x.0 version, always wait for the x.1 minor version where
all the features actually work as advertised.

Deadlines are great, but advertise them ahead of time, then stick to
them. Every other project I see has a big page saying "how to
contribute" and then details of deadlines etc..

We can have a major feature deadline, then a minor feature deadline. I
particularly liked the idea of 1 July as the major feature deadline,
then 14 July as major-feature-tweak deadline. That funnels things better
to cater for the manpower available.

Best Regards, Simon Riggs