> things. Extreme example: In Plone the core Plone product is called > CMFPlone. It pisses Alexander off. Should we rename it 'Plone' and thus > break every product that ever imported from CMFPlone? Should we make a > jungle of aliases and deprecation warnings? Or should we live with our > mistakes? In this case, the benefit is marginal and the potential > confusion and breakage is high. That trade-off point moves with time, > though, as the more major parts of the framework become "right" and as the > user base increases. However, that same user base will not increase beyond > those who are so well-informed that they know what they're getting > themselves into, if the software gets a reputation for breaking your code. > > I guess the question is, how far along that curve is Zope 3? How far along > does it want to be?
It's curvature point is 6.3 milliMartins. ;-) There are methods for neatly deprecating things like this, and they have been employed consitently in Zope 3, and quite consistetly in later versions of Zope2. For example, in Zope 2.8 the whole Zope package was renamed Zope2. The Zope.py backwards compatibility handler will be removed in Zope 2.11. I'm not aware of this causing any problems. So to answer your question: If you make do not update your Zope version for more than a year, then you may find that your products is no longer compatible. The solution to that will be to jump two major versions at a time, and remove any deprecation warnings you see. For example. If you now use Zope 3.2 to write an application, and you in the beginnig of 2008 decide to install Zope 3.6, which should come out in November 2007, you may find that you get an import error, or that a zcml statement you do is no longer recognized. The solution is to instead try with Zope 3.4. It should work, but the import errors and unkown statements should now instead be converted to deprecation warnings, conveniently telling you what to do instead. You fix those, and when there are no more deprecation warnings in your code, you switch to 3.6. Maybe you have more deprecation warnings, so then you fix them too. Then after that, you are all set for 3.6, 3.7 and 3.8. That's the idea. But who know how things will look in 2008!? We could all have been wiped out by an interplanetary virus or something... :-) Rule #1 in computing: Things never go as you plan and the future changes to fast for you to keep up. So don't try to do things to accomodate the future, because it is never gonna look as you thought it would. This is the basis of the YAGNI rule in XP development, and this is the basis of my rule in computer management: Do what works today. Don't wait for something that might work tomorrow, because it ain't gonna. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com