Martijn Faassen wrote at 2008-12-19 22:18 +0100:
.... On Fri, Dec 19, 2008 at 7:50 PM, Dieter Maurer <dieter@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.
That's your point of view -- mine is different (maybe, because my frameworks are much smaller).
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.
My components will only depend on some of the (future) Zope 2 components in an essential way. Others may significantly change without a serious effect on my components. Thus, I will document in a way similar to "tested with Zope 2.8, 2.9, 2.10; ZODB 3.2, 3.3, 3.4". -- Dieter