On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer <die...@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).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -