Guido, As I see it:- - you're not going to please everybody. - you're not even going to please most people. - you'll be lucky to please a good proportion (say a quarter to a third) of your active user (as in developers writing Python apps) base. All I think you'll be able to do:- - try and make your development plans and release functionality goals more explicit and widely known; - use your limited development resources in much the same way as you currently do; - make a decision as to whether fixing warts at the cost of backward compatibility is better than preserving warts in perpetuity. [long-winded rambling attempt to support above statements...] It all comes down to perception. Release version numbers are both a blessing and a curse, which is why Microsoft has tried desperately to find some other code to identify releases without implying functional performance or API compatibility. There is this perception that a "minor" release number has a specific meaning, and a "patch" or "fix" release number has an even more specific meaning. We even have a PEP spelling it out. In the scheme of things, you may have had a somewhat different response had the following version numbers been used instead: 2.0 => 2.0 2.0.1 => 2.1 2.1 => 2.5 2.1.1 => 2.6 2.1.2 => 2.7 2.1.3 => 2.8 2.2 => 3.0 2.2.1 => 3.1 2.3 => 4.0 (or perhaps 3.5) I'm not saying the response would be more favourable, just different, as different people would read different things from this different set of tea-leaves. Part of the perception problem that I think Paul Rubin and others are exhibiting symptoms of is the implied development road-map associated with version numbering. A corporate software development effort has to take a longish time to consolidate its development plans, and match them up with code developed and bugs/misfeatures/limitations resolved. Hence a 2-3 year major release cycle, with the odd bug-fix release to pacify those on maintenance contracts. People steeped in this sort of corporate ecology find this stability comforting, and the apparently well defined development roadmap reassuring. Because Python isn't the centre of a commercial development effort, its development isn't as well defined as some might expect. Indeed, as with most open source projects, its developers scratch their own itches because they aren't being paid to scratch someone elses. Python is also subject to much tighter resource constraints than I would expect of any commercial effort to do the same task. Consequently, the development plans are more fluid and the delivery schedule more variable. There is also the sense that completed work should be released for use, rather than being hoarded until it fits in with the "grand plan" of the major release cycle. This is in keeping with the "release early, release often" mantra espoused by ESR as an ethic of open source development - the Bazaar. But its antithetical to a corporate ecology - the Cathedral. On the resourcing topic, despite your offers of the keys to the "stable" branches in CVS to anyone who might wish take them on, the only result has been individuals stepping up and doing one "fix" release and then retiring burnt out. This points to the extreme cost of managing "bug fixes" only releases in the midst of active development. Something those who demand such releases (especially those without a maintenance contract to fund the work) don't and probably won't acknowledge. While Alex's "stable" and "development" branch thinking is attractive, I don't believe that the current or likely future resources can sustain it. I also believe that it would be counterproductive to even try it out, in that the resources expended in the effort are IMHO must unlikely to produce any usable return. There is also the matter of backward compatibility. My experience has been that beyond a certain point, the burden of maintaining backward compatibility raises the cost of further enhancement to unacceptable levels. As I prefer to keep making progress, rather than be forever looking back into the past, I expect that backward compatibility should be balanced against the need for progress, and is therefore not sacrosanct though it should be retained where possible/practical. I've already wasted too much of my own resources on this (not to mention yours or those of anyone who has read all the above), so I'll just close by saying that I admire your juggling act, and have faith in what you're doing with Python, even though there are small (in the scheme of things) quibbles I have with some of your decisions. Regards, Andrew. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370 andymac@pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia