[Zope-dev] Re: Time-based releases a good idea?

[Philipp von Weitershausen]

Chris McDonough wrote:
> On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote:
>> We've had two ZPT implementations, now we have to maintain only one. We
>> had our own logging framework, now we can simply use Python's, etc.
>> These changes may seem cosmetic to the outside developer (he has to use
>> different APIs), but they're essential to us as to how much code we want
>> to have maintained or, in the worst case, bitrotting in our source tree.
>> I'll note that even the outside developer may benefit from our using
>> more standard libraries, because they might already been known to him.
>> Even more so, they're already documented by someone else. (Was zLOG ever
>> documented? I don't think so. But the 'logging' module is.)
> 
> The zLOG removal will break far more third-party code than any other API
> change we've talked about so far.  The cost of each API change needs to
> be weighed against its benefit.  This is one of those cases where
> backwards compatibility was free; the code was already there.  zLOG was
> just a tiny shim that called into the logging module.   Removing it is
> gratuitous.  In general, this change is the definition of cosmetic.

Well, except that the actual, formal deprecation of zLOG finally made
everyone aware of the logging module and a few things like logging
levels that no one had thought about till then. So I wouldn't say the
benefit was exactly zero... whether it ways out agianst the costs I
don't think I can say at this point.

> For what it's worth, maybe there's some middle ground here.  Just
> because something is deprecated doesn't need it needs to have a hard
> date to be removed.  Why don't we just have the first use of zLOG in
> each module generate a deprecation warning and just leave it there
> forever?

Or make it available optionally. After all, it's just a Python module.
Perhaps we should put up the latest version from Zope 2.10 as a separate
egg on the cheeseshop. People can then just ez_install it if their
product still happens to need it...

> People will get sick of seeing the warnings, and they'll
> eventually change it, but there's just no reason to *force* them to
> change it on our time schedule.  And if they don't, who cares?  People
> who don't want to see the warnings can filter them out.
> 
> I'm also for reducing duplication, but only to the point that it does
> not large amounts of break running code.  We have yet to see what the
> real fallout of changing to the Z3 ZPT implementation is.  It may be a
> pure win, but I wouldn't declare victory just yet, at least until we
> have some empirical evidence that it doesn't break large existing
> codebases.

Oh, I absolutely agree. Zope 2.10 will need strong testing mostly
because the ZPT implementation. This was a pretty major change, the few
heavy discussions we had so far already are good evidence of that (e.g.
the one on empty path expressions). Given all that, it's still a thing
we wanted to do and are happy to do. I agree, we can't declare victory
on the whole war yet, but at least on a few battles... :)

>> * moving to more Zope 3 technology.
>>
>> We've managed to introduce Zope 3 technology in a couple of isolated
>> areas in Zope 2, e.g. i18n, views, object events. So far, we've only
>> seen deprecation warnings in the field of events where the old manage_*
>> methods have been deprecated. Zope 3's event system is superior to the
>> methhod overriding in Zope 2, hence we're evolving Zope 2. People *want*
>> to use Zope 3 technology in Zope 2 more and more and currently the
>> framework it's stopping them in many ways. Five, on the other hand, is
>> just a (very large by now) compatibility layer (with lots of code
>> duplication) to which the first point shall also apply: we should try to
>> make code in Five smaller by evolving Zope 2.
> 
> There are reasons we are bothering to change the Zope 2 APIs at this
> point instead of all of us moving to Zope 3 wholesale.  One reason is
> because we've figured out that in the real world backwards compatibility
> and familiarity are primary drivers for take-up of technology.  Let's
> please not forget that again, and let's be careful.

I agree. This is why we need watch each other's steps and discuss the
things. This has coined the term "checkin police" in Zope 3. We already
have it in Zope 2, but somehow it has failed this time... This whole
discussion has uncovered lots of stacked up frustration, it seems; it
could have been held a lot earlier, I guess (from both sides).

Philipp