A> On Tue, Apr 09, 2002, M.-A. Lemburg wrote:
Regarding the subject line: don't know if it's just me, but I would like to see some of the conservative development style we had established a few years ago return in Python's development process. Some of the recent developments left me under the impression of the need to rush changes with no apparent reason (for rushing them).
A> Or, to put it another way, perhaps before development work for A> each release starts (aside from bug fixes), we draw up a list of A> the feature goals for that release and project a target date for A> finishing those goals, but the goals get the focus rather than A> the date. Changing goals after development starts would require A> official BDFL prounouncement.
That's pretty much what we do now, isn't it?
We consider both a set of functional goals and a release schedule. We don't want to make these decisions in isolation. If there are N features in the release, and all but 1 can be finished in six months, we don't want to hold them all up for one feature that takes two years. So we say the next release will have N-1 features, and the other feature will go in a future release.
A> If a great feature comes up after development starts, too bad -- A> the next development cycle will usually be less than nine months A> away.
The only person sneaking in new features is Guido <0.2 wink>.