[Python-Dev] Re: Stability and change

[Skip Montanaro]

    >> Over time people should become aware that odd-numbered minor releases
    >> are always development releases and are not to be relied upon.

    Michael> In which case you might as well not release "odd-numbered minor
    Michael> releases" becuase 90+% of the people who would use them get
    Michael> Python from CVS anyway.

You still need releases.  I'm advocating a completely different way of
deciding when to release, however.  Instead of generating PEP 283 (Python
2.3 Release Schedule), the timing of when to split the experimental branch
should be driven by completeness of the functional goals for that branch and
the bug fix rate for that branch.  This is not a commercial enterprise.  I
don't think there is a "market window" that has to be hit that should
dictate, "we have to release 2.3 in mid-August, regardless of what else is
going on."  When you have a time-driven schedule, I think there is a
temptation to find "something new" to put into every release.

Measuring bug fix rate can be done directly by keeping historical
information on the number of SF bugs closed per week (my little weekly
script goes partway there now, I suppose).  I suggest that the Release
Schedule PEPs instead become Goal PEPs that record the goals for the next
release and their status as well has bug fix information for the current
micro release.

Repeat after me: Experimental micro releases should be cheap.

Skip