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

[Philipp von Weitershausen]

Tres Seaver wrote:
> Lennart Regebro wrote:
>>> On 6/14/06, Chris McDonough <chrism at plope.com> wrote:
>>>> The time-based release cycle just amplifies this across many branches
>>>> and point releases, so nobody really knows which products work with
>>>> what branch/release and under what configuration some feature is
>>>> supposed to emit a deprecation warning without a good deal of
>>>> testing.  The *reason* I'm stuck back on 2.8 and haven't upgraded the
>>>> products I maintain to behave nicely on 2.9+ is because I just can't
>>>> keep the fuck up with these sorts of changes.  It's a self-
>>>> perpetuating cycle because the only sane defensive maneuver for me is
>>>> to stick with 2.8 for existing customer projects.  I say to myself
>>>> that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to
>>>> be the current release once I get a chance to breathe, but honestly,
>>>> this is the *last* thing I'll do; I've got plenty of other coding to do.
>>> Well, ignoring the confusion about zLOG, updating things for a new
>>> version of Zope with deprecation warnings is not much work. Honestly.
>>> You update to the new version, look at the depracation warnings, and
>>> do search/replace until they go away.
>>>
>>> Unless their are compatibility bugs, and that will happen sometimes,
>>> that's it.
>>>
>>> I don't remember exactly how long it took to go to 2.9 for CPS, but it
>>> wasn't very much work, and it was all related to changes in Five,
>>> which you don't seem to use or worry about.
> 
> Bzzt.  Five is a *major* culprit for us (Chris and I are often working
> together).  The "lookup order" BBB foul in 2.9.2 is one of the major
> reasons for sticking to 2.8.

I think we've been over this. It's not really a BBB foul because I
classified it as a bug when I found out about the issue
(http://codespeak.net/pipermail/z3-five/2006q1/001186.html). The
rationale behind this thinking is being closer to Zope 3's behaviour
where folder/foo would first look up the 'foo' item in the folder, then
the @@foo view.

I think we've also come to an agreement to make this pluggable. I don't
remember anything happening, though. For all I care, we can go back to
the old behaviour with the only exception that ObjectManagers are
traversed attributes-first-views-later. Views should not shadow
contained items.

Philipp