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 your internal applications as well. :-) (Note that you can now override versions using the new "extends" feature that I shamelessly copied from buildout.) And I am not saying this to promote the KGS. I have a concrete example. Probably as part of a project, Benji did some development on zope.testbrowser. He fixed the versions of all dependencies in buildout.cfg. However, those 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 to "dev" 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 dependency graph. The worst scenario, which luckily has not happened yet, is that we fix things back and forth because of different dependency graphs. I thus propose that all packages in svn.zope.org should use a KGS for testing, because it is a fully public dependency graph. I am not sure whether it should be the latest stable KGS or the development KGS or whatever. Time will provide an answer. BTW, Benji wanted me to bring this issue up on the mailing list already, so I fulfilled my commitment now. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training _______________________________________________ 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 )