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

Skip Montanaro skip@pobox.com
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