"Max Ischenko" <[EMAIL PROTECTED]> writes:
> The larger question is: while moving to CherryPy 3, is TurboGears
> responsible for providing compatibility-layer API for clients or let them
> break (like TurboZSI)?
I would love seeing a compatibility-layer... BUT then we'd have a huge
ammount of code that's there just because of that, that can break, that we'd
have to maintain and that would bring us two other problems:
- when should it be deprecated?
- why would extension writers worry with updating their extensions if
they didn't stop working?
The last one is the worst. I've developed some widgets for internal use, and
I remember only updating two of them when they broke and I really wanted to
upgrade. It will happen in a large scale if we have compatibility layers.
(Then, we'd also need something for SQL Object, later for SQL Alchemy, then
Genshi -- remember that it will now raise exceptions for undefined
variables... --, etc.)
I believe that saying: if you want to use thing X then use a version up to Y;
other developers have already upgraded their Z thing to W version.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
