Hi all, this sounds sensible:
* <http://www.artima.com/weblogs/viewpost.jsp?thread=227041>: > 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 > fix. 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? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
