Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Before we settle on any dates I think we should have some discussion
>> about how we can shorten the period between feature freeze and beta,
>> which was far too long this time. Perhaps we need to be more aggressive
>> about what what makes the cut and what doesn't.
> [ thinks for a bit... ] A truly hard-nosed approach would be to define
> FF as "if your patch isn't committed by the FF date, you lose". The
> FF-to-beta delay then is only long enough to make sure we've documented
> everything, written release notes, etc. I'm not sure this would be a
> more pleasant way to work, as there'd be a heck of a lot of pressure on
> the committers as the days tick down to FF. But it'd fix the scheduling
> problem.
I actually don't disagree with anything you have to say but would like
to offer one other thought. Instead of a hard feature freeze, we offer a
continual development model. In short, we develop, review, commit etc..
until we feel a need to release.
Certainly we don't want to be releasing every 4 years but then again, in
reality 8.3 could have been released 6 months ago, should we decided,
hey... Tsearch2 and Hot.. well they aren't done so they get 8.4 and
perhaps because Tsearch2 and HOT are so cool, once they went in, even
though it is only 6 months later, it would be worth while to release
8.4. If we followed this model, we would be pushing 8.4 beta1 right now,
not 8.3.
Further the people wanting specific features of a specific release,
don't have to wait 12-15 months to get them.
I recognize this would be a *lot* easier if we didn't have the initdb
requirement but still... release early, release often.
I have really taken to the Ubuntu style of releasing. Every 6 months (or
so) they release. Every 2 years (or so) the LTS.
Is there potential for that here? I don't know, but it seems worth
exploring.
Sincerely,
Joshua D. Drake