[Python-Dev] Re: Stability and change (original) (raw)

Skip Montanaro skip@pobox.com
Mon, 8 Apr 2002 15:56:28 -0500 

Alex> But SOMEthing more remarkable that "up to 2.3.N experimental,
Alex> 2.3.(N+1) and on stable" is needed -- a different name, a
Alex> different major release, whatever.

It seems to me that having functional goals for development releases is the right way to measure functional completeness and stability. If you have this list of goals, that provides a way to directly measure functional completeness. Once a development release is functionally complete, perhaps you can begin to measure the bug fix frequency more-or-less independent of the functional change frequency. Once the branch is functionally complete and bug fix frequency drops "sufficiently" far, you've reached a point where your confidence in splitting into new stable and development branches makes sense.

Another motivator might be the presence of impending new development. Suppose MAL has submitted a complete rewrite of Python's Unicode handling , but your currently at 2.3.13 and feeling pretty good about the stability of that code. You fork into 2.4.0 and 2.5.0. MAL's new Unicode implementation can be at the top of the list for 2.5's goals and go into 2.5.x. 2.4.x can then pick up more bug fixes. By the time you reach 2.4.2 or thereabouts, people should be really comfortable with the stability of that code.

Skip