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. :-)
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -