this sounds sensible:
> I implore you (especially if you’re maintaining a library
> that’s used by others) not to make incompatible changes to your
> API. If you *have* to make API changes, do them *before* you
> port to 3.0 – release a version with the new API for Python
> 2.5, or 2.6 if you must. (Or do it later, *after* you’ve
> released a port to 3.0 without adding new features.)
> Why? Think of your users. Suppose Ima Lumberjack has
> implemented a web 2.0 app for managing his sawmill. Ima is a
> happy user of your most excellent web 2.0 framework. Now Ima
> wants to upgrade his app to Py3k. He waits until you have
> ported your framework to Py3k. He does everything by the books,
> runs his source code through the 2to3 tool, and starts testing.
> Imagine his despair when the tests fail: how is he going to
> tell whether the breakage is due to your API changes or due to
> his own code not being Py3k-ready?
> On the other hand, if port your web 2.0 framework to Py3k
> *without* making API changes, Ima’s task is much more focused:
> the bugs he is left with after running 2to3 are definitely in
> his own code, which (presumably :-) he knows how to debug and
And the Don’t Break CPAN line:
> The same recommendation applies even more strongly if your
> library is a dependency for other libraries – due to the
> fan-out the pain caused to others multiplies.
Sounds quite well reasoned to me. Is this something that makes
sense to encourage for 5-to-6 migrations of Perl code as well?
Aristotle Pagaltzis // <http://plasmasturm.org/>