Hi Sam -- Well, I don't type nearly as fast. :-)
This whole thread started off with a message change. Changing an error message is not changing an API! I return to the original statement that the user of the framework is the developer. And the developer should always control the output to their end-user. To rely on defaults is just asking for trouble. For Jesse, or anyone else should not have to worry about maintaining precisely the same error message. I would rather have him worry about fixing bugs, adding documentation, examples, and adding new features. Take this thread to any other open source project and complain about a error message changing across versions. I have $5 that it is ignored or ridiculed. For the projects I listed, for the most part, they never changed because the existing framework worked good enough. And have a fancy new framework was never worth it - so you would lose the argument about "them wanting to upgrade" - management doesn't care - they care more about the custom features.
From my perspective, having a library get too hung up on backward
compatibility is an invitation to stagnation. I much rather have a library that is willing to discard old API's (with appropriate intermediate releases, labeling an API as deprecated.) To me that is a sign that the library maintainers recognize when they made an error in the original design and are correcting it. Or maybe the world headed in a different direction and the library needs to adapt to accommodate the new users' needs. New users will not scream on these email lists that a library is too cluttered with defunct or difficult APIs that are maintained only for 'backward' compatability. They will simply go away. I have said all that I can say about this. -Pat
