[Python-Dev] Re: Stability and change

Mon, 8 Apr 2002 17:37:49 -0500

 Jeremy> It seems like adopting a Linux-style development branch makes
 Jeremy> lots of extra work and doesn't buy Python much extra testing or
 Jeremy> stability. What you're calling experimental releases, we
 Jeremy> currently call cvs checkout :-). I'm happy to keep truly
 Jeremy> experimental stuff in CVS between releases and aim for stability
 Jeremy> with each 2.x / minor release.
Perhaps you're right. The problem with simply dealing off the top of the
CVS deck is that it provides no way to conclusively state that the current
CVS head is either more functionally complete or more bug-free than an
earlier CVS head. Hopefully releases will be must smaller efforts than they
currently are. Pulling away from SF for releases will certainly help. If a
micro release on the development branch can asymptotically approach
 * create a baseline named devel-2.N.x
 * drop a tarfile onto www.python.org
 * send out an email
I think you could probably justify making releases on that branch every
month or so. Releases on the stable branch would probably occur less
frequently (only when a sufficient number of bug fixes had accumulated or a
particularly serious bug fix was applied to the branch) and be a bit more
involved (maybe involving creation of a Windows installer).
Above and beyond the notion of complexity or technical superiority of
different development models, I think you need to realize a positive PR
advantage from a change in development models. If you could produce a table
like
 Version Bugs fixed
 ------- ----------
 2.4.1 47
 2.4.2 32
 2.4.3 12
 2.4.4 3
you would go a long way toward arguing that "stable" branches are really
getting more stable. Similarly, such a table on the development branch
might help developers decide if the development branch is stable enough to
fork.
Skip