We're not rewriting Zope 3 every time ===================================== Sometimes I get the feeling some people think that we're rewriting Zope 3 with every new major release. That all of their code will stop working. That they need to spend endless hours to port their code. Well, to be fair, nobody has actually said this. It's just an exaggerated impression I have from all the constant whining about this. Yes, whining. On IRC, on mailinglists, talking to people in person. Funny is, most of the whining is from people who haven't even used Zope 3 or `had to port a Zope 3 application `_. Part of this impression is that people seem to think we actually like deprecating things, just because things would be "cleaner", more "pythonic" or because it's Tuesday (c'mon, that was a joke). Jean-Marc writes in his `recent post `_ that "there should be *real reasons* for deprecating" [emphasis quoted from original]. That makes it sound we don't have "real" reasons (whatever this means). So: Are we doing this just for fun? ------------------------------- We're not. The Zope development process puts the bar very high for massive changes such as adding new features, getting rid of things and refactoring things: * They can only happen in major releases. Bugfix releases will never see such kind of instability. * You have to write a proposal outlining the current situation, the problem you see with it, the change you propose, and the risks that the change poses. * The proposal is discussed and possibly altered after the discussion (it happened to my proposals every time, and I'm glad because they were much improved). * If accepted (many of my proposals were shot down, which is ok), the proposal implemented and will appear in the new release. Now, here's the important part: **Backward-compatibility has to be provided.** That's right, no change without proper backward compatibility! And believe me, getting backward-compatibility right is hard, so we think twice about every change we make. So, the bar for invasive changes is high, and they don't happen that often because of that. But: Why **do** they happen then? ---------------------------- Because we're not smart enough get things right the first time. Are you? Deprecating something means admitting that the current way of doing things was a mistake. It also means that we're fixing with a better way (That's important! we don't deprecate things without providing an alternate way of doing things). In his most recent post, Jean-Marc `quotes a document `_ that says: Valid reasons for wishing one's users to migrate to the new API include: * the old API is insecure, buggy, or highly inefficient * the old API is going away in a future release * the old API encourages very bad coding practices Jean-Marc goes on to say that deprecation shouldn't happen "simply because the code needs to be restructured or refactored, or packages be moved from zope.app to zope." That makes it sound those efforts (the restructuring, refactoring and moving packages) does not happen for any of the reasons quoted above. Well, they do: * The Component Architecture was refactored twice (once visibly from X3 3.0 to 3.1 and once not so visibly from 3.2 to 3.3) because **it was highly inefficient** to use. * The moving of certain packages is actually not even an API change (only imports change, not APIs), so technically you could argue that the reasons above don't even have to apply. But here it is: Having a big zope.app package is **encourages very bad coding practices**, because zope.app packages were depending on each other wildly, making it hard to redistribute them. * And finally, the ZCML directives I deprecated were **going away in future releases**. Hah, that's a simple one :). Conclusion ---------- Overall, the two messages I'm trying to send out are those: * We're not deprecating things for fun. Deprecation is a necessary evil sometimes to overcome limitations, excessive complexity or just plain stupidity from the past. A good deprecation practice shows that we actually care about improving the framework. * The bar for deprecation is high and has to be high. We discuss changes beforehand and we have a "check-in police" that rings the alarm bells after the changes if necessary. And don't get me wrong, there **has** been jusified criticism about the deprecation practice in the past. Tres Seaver has warned several times that we need to watch out for "janitorial deprecation" and Martijn Faassen has been collecting some ideas of how to improve the documentation of deprecation changes, apart from the proposals we do write and the descriptive deprecation messages we already generate. If you have suggestions or ideas, please contribute them. Just saying "the deprecation has to stop" is not helping.