[Zope3-dev] Re: Who would use this crazy thing called Zope 3?

[Lennart Regebro]

> 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/