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
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.
I think you make a good point.
+1 on using *some* KGS.
Jim
--
Jim Fulton
Zope Corporation
_______________________________________________
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 )
