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