Again this appears to be arguing for what we already do. Maybe with one difference: I assure people on c.l.py that PLabs will continue distributing I.J.K for increasing K for as long as the community contributes the work for bugfix releases. Perhaps you're saying that PLabs should take that over?
No, this is for all active developers.
I agree that we don't have to change what we do very much, but I'm looking for a way to "spin" it to satisfy the more conservative user community (the ones who still like Python but are worried about the future).
Since there are different "use cases", this may be hard or impossible, or we may have to explain it differently for different folks.
For example, developers who distribute useful Python programs want to have a way to ensure that code they write gets run on a compatible Python version. We could make it easier to have different X.Y releases installed on the same system; this is already pretty easy on Unix if you know about "make altinstall". If we invent a standard way to specify the required version (or range of versions?) then that might be sufficient. You shot down my #! proposal for Windows, but maybe we can do something else. (Obviously this only works for programs, not for modules or packages. Package authors pretty much know the drill.)
Beginning programmers have a different concern: they don't know much about software evolution, Python may be the first or second language they learn, and they hear that there's a concern about the rate of change. How can they know what that means? I've seen plenty of posts from such people worrying that in a few years from now they might have to learn a whole new language. They needn't worry, but it needs to be addressed with more explanation than "don't worry, the BDFL is watching over you."
I'm not sure what exactly we need to do now. Be clearer to the user community that we're still maintaining 2.1.*?
Are we? We've made no effort to backport any bugfixes into 2.1.3, and to the contrary declared that we wouldn't do anything with 2.1.3 except fix the single gc-vs-trashcan disaster. We're not even building a Windows installer for 2.1.3 (last I heard). I don't think anyone is going to buy that as "maintaining" the 2.1.x series; I sure don't.
Maybe we need to use a different word? Barry noted that 2.1.x is the most popular "stable" release and will probably remain that. So maybe we should say this is the "recommended" release. And then maybe we need to revise the decision not to make a Windows installer. Or maybe we do need to spend more effort backporting patches (not necessarily PLabs, but somebody).
Another way to keep adding value to older releases is by backporting the build procedure enhancements. Once we've figured out how to build Python 2.3 on, say, some ancient version of AIX, maybe somebody should port that back to 2.2 and 2.1. That's not a language change, but still improves the usability of the release. (For some folks. Maybe the AIX user community is small enough that we shouldn't care, but there are other platforms with similar issues. I recall that you backported the new 32 bit Windows installer to 2.1.2; maybe the recent fixes could be backported to 2.1.3.)
OK, so I am proposing to do something different. Maybe it's not very attractive to work on old releases. But Zope Corp does it all the time (and the fact that Zope 2.x requires Python 2.1.x may be an additional motivator).
Delay the 2.3 release and spend more time on 2.2.2 (assuming that 2.2.1 is about to go out)?
2.2 did go out the door unfinished <wink>. But, again, we could have delayed it two years and it still would have been relatively unstable: there's just no substitute for getting thousands of users using a release.
... While I agree that 2.1.x is the most stable release, there's also a significant user population who want to use 2.2 (e.g. the new Boost library wrappers use new-style classes). We should maintain the 2.2.x line for their benefit. And then maybe we could take our time releasing 2.3 while experimenting with new features to our heart's content. To counteract the fact (as Tim noted) that few users bother to download betas, maybe we could release 2.3 relatively rough, clearly mark it as an experimental release, and work on improvements and stability in 2.3.1, 2.3.2 and so on, until we're happy to call it stable and start experimenting with 2.4. While we're working the kinks out of 2.3.x, the most stable release advertised would be 2.1.x, and adventurous users could basically choose between 2.2.x (advanced but stable) or 2.3.x (bleeding edge).
You can fiddle what you call what we're already doing anything you want, but if a long-lived two-branch comes out of this, I quit
Would you settle for a separate CVS repository? :-)
I do believe we should direct more effort into bugfix releases; that can't be done without taking away from something else, though (that's a trivial deduction: everyone is already overloaded).
Yup. That's why we need to put some effort in communication to the users, and some in a real change of priorities.
--Guido van Rossum (home page: http://www.python.org/~guido/)