On Nov 11, 2007, at 6:34 PM, Stephan Richter wrote:
On Sunday 11 November 2007, Jim Fulton wrote:
This breaks a fundamental assumption for releases. When I release
something, I expect it to work tomorrow, next month, and next year.
If you want this, then you can't rely on the KGS. When releasing our
applications, we don't rely on a KGS. We fix all of the versions
we're using. IMO, the KGS shouldn't try to solve this problem. A
KGS should be helpful for developers and development frameworks. A
KGS will be more useful if the quality remains high. A KGS is
similar to a traditional monolithic release. After all, bug fix Zope
releases have been known to break applications too.
I really hope you will use the KGS as a starting point somewhen for
internal applications as well. :-) (Note that you can now override
using the new "extends" feature that I shamelessly copied from
And I am not saying this to promote the KGS. I have a concrete
Probably as part of a project, Benji did some development on
He fixed the versions of all dependencies in buildout.cfg. However,
versions were a version sub-graph of a ZC internal dependency graph
that I do
not have access to. It was also already pretty outdated referring
and "alpha" releases.
So while testbrowser might be working with those dependency
versions, it might
still be broken for me, because I have a totally different
The worst scenario, which luckily has not happened yet, is that we
back and forth because of different dependency graphs.
I thus propose that all packages in svn.zope.org should use a KGS
because it is a fully public dependency graph. I am not sure
should be the latest stable KGS or the development KGS or whatever.
provide an answer.
I think you make a good point.
+1 on using *some* KGS.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -