On Monday 08 April 2002 21:26, Guido van Rossum wrote: ...
True, and yet such decision makers DO want to perceive that the specific software they use IS actively supported. It's a reasonable desire indeed, as I've tried to explain quite a few times.
Yet it is close to Logajan's position.
I dispute that, even though he himself appears to be judging from one post he made to c.l.p -- which I answered trying to dispell his false hopes in the matter. He wants to ensure that software that runs on (e.g.) 2.(N+1) must also have run on 2.N : this is unreasonable, and I've never heard anybody else ask for that. He also seems to want this to hold across major release number changes, 1. to 2. -- and again that does not seem to be a widespread priority.
If they perceive that choosing "Python in general" means they have to choose between an "old, not actively supported any more" version of the language, and one that breaks previously working code every six months, then that will weigh on their mind as a big minus for Python.
So it's purely a matter of spin. Because new Python releases every 6 months do not mean that code breaks every 6 months. Yet some people continue to believe this.
I may be wrong, but I think that the fact that doctests DO break with every release has something to do with this perception. doctest is SO nice, easy and natural to use (within a single release) that it's hard to accept it as "unusable between minor releases", even though I have to reluctantly accept that decision.
If they perceived they could choose a "stable but actively supported" version (the existence of an experimental one too would not worry them, I believe -- many popular languages sprout experimental ones based on them too) then that worry would be out of the way, and I'd have a better chance to get them to LOOK at the huge productivity improvements Python has in wait for them...
Maybe all we need to do is make the micro releases a bit more visible...
I may be wrong, but I think the concept of dual, stable and experimental, tracks, already familiar and accepted from other pieces of software, would facilitate prospective user's perception of "stable but actively supported software".