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
<wink>, 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4