Hey, 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). Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )