[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]

[Martijn Faassen]

Hey,

On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer <dieter at handshake.de> wrote:
> Martijn Faassen wrote at 2008-12-18 16:27 +0100:
>> ...
>>You should, and likely are, shipping your package with a recommended
>>list of versions.
>
> Apparently, "grok" was forced to go this route.
> But, in principle, this is undesirable.

No, it's very desirable if you want to provide a stable platform at
all. A platform is *not* stable if each time a new user installs it he
might end up with a different set of "latest" versions - there's just
no way to communicate about bugs if it's that way. It's also just not
right to force all the users of a framework to make the determination
which version to use for dozens of packages. The idea of using a
framework is to make life easier, not harder.

> Most of my components work with a wide version range of other
> components. I would not like to expose a single version.
> Usually, I include a narrative of the form: known to work with 2.6.x
> through 2.11.x; may work with other versions as well (not tested).

What will you do once Zope 2 is split up into multiple packages? How
would you express such a thing about Zope 3 if there is no canonical
list of versions (such as KGS)? Grok is in the position of Zope 2 or
Zope 3 here.

Of course we prefer the individual components that Grok is composed
of, and extensions to Grok, to work with multiple versions of Grok.
That's unrelated to the need to actually *have* versions of Grok in
the first place. It's desirable to have each component work with a
range of versions of other components. It's also desirable to make a
collection of components work out of the box with a well-known set of
versions that can be communicated about, because this selection itself
has a version number as well.

> In the past, I have seen excessive deprecation warnings and had
> the feeling that the warning feature is overused (as many new features).

I think it's clear that many people do not like seeing deprecation
warnings during startup and runtime and that it's been quite a burden
on developers. I can see how it is frustrating to developers (one or
multiple steps away)/

It's also clear to me that if we want Zope 3 to move forward, we need
a much less convoluted dependency structure and have the ability to do
some relatively bold refactoring. We will therefore need to move
things around a lot more, and I fully intend to make progress on that,
and join Roger in his work.

I therefore propose we make a new kind of deprecation system that uses
the same system to mark up source code as we have now, but does never
emit the warnings during run-time. Instead we create an external
scanning tool that can report about deprecated imports in a package
(and perhaps help fix them automatically).

Regards,

Martijn