On Tue, Feb 20, 2001 at 12:20:27PM -0500, Barry A. Warsaw wrote:
First, I don't buy the backwards compatibility argument. Yes, some code broke, but it was broken anyway (people using undocumented APIs). The broken code is easily fixed.
That is not something you can sell very easily, Barry. From the perspective of providing a service to a lot of third parties, with at best a varying cluelevel, upgrading is a very scary thing. I may seem very conservative on python-dev, wrt. backwards compatibility, but I assure you I'm quite the radical compared to some people, and compared to myself when considering upgrades on production platforms :)
For instance, because we run webservers that serve over 10k domains, I am very cautious in upgrading Apache, PHP or GD-lib on those machines. Yet every time I do it, after careful consideration, I 'break' some websites that were conciously or unconciously depending on a bug in some piece of that software, or linked to a fixed version of a library, or using an obsolete API. They might have been wrong in doing so, but from their perspective it's very simple: it worked, *we* changed something, and now it no longer works.
Nevertheless I do think Debian is going a bit over the wall in this case, since they have a very clear distinction between stable, testing and unstable trees. They could certainly switch python to python2 in the unstable tree, since it'll be some time before that tree is going into testing, and more yet before it's stable. It may have something to do with the missing readline support in python2, though -- the disabling of modules people might depend on falls under backwards compatibility again :)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!