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
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