> Betreff: [Zope-dev] why external version indexes don't
> fulfill all use casesfor development
> Hi there,
> I've been doing some more thinking about external version
> indexes (like Grok's versions.cfg on a URL, and like KGS) and
> why they won't solve all our problems. I have a new way to
> express it, so let me try it out on you all.
> What KGS solves is that it allows the ongoing development and
> testing of an integrated Zope 3. That is, there's a Zope 3
> 'trunk' of versions that keeps being updated as there are
> bugfix releases. I'm not sure what happens as soon as someone
> wants to make a new feature release of any package.
> Presumably they end up in KGS too. After all, we won't have a
> single Zope 3.4 and then a single Zope 3.5 for which we can
> create a new KGS. We intend to let packages move at different
> feature-release speeds, and we can't have a KGS for each package.
I hope I can show you another point of view, but I'm not sure
if this is understandable what I'll try to explain ;-)
Yes, a KGS is a policy which makes sure that we can reproduce
the dependency list and build a base for your custom development.
Or we can use it as a base for reproducable bugfix. KGS is
also comparable with a (daily, monthly or whatever) snapshot.
And yes, there will be more then one KGS, there will be a
development KGS that allows us to develope in a community.
Because probably someone likes to develop 3.6.1 and other still
work on 3.5.9.
The KGS 3.4 reflects the tags folder compared to subversion
and the KGS 3.5 dev will reflect the ongoing development
compared with the subversion trunk.
Anyway, a KGS is only a definition of what works with what.
It doesn't matter if we call it KGS or something else,
if you need to build grok or a custom set of eggs for
your project you will need to know which version of
eggs your project will use. That's the part what KGS can
Every egg version which is fixed in a package can break
what you are trying to assamble. Because versions in eggs
depend on the overall snapshot concept and don't know
future versions of other eggs.
The KGS can solve the problem because a KGS is a snapshot
view on what you are trying to assamble. Eggs can't do that
I'm 100% sure that we are not able to solve the dependencies
at the package level. Or at least not without to restrict
and lock down packages. Because you will lock down versions
in zope package because grok will break but other projects
Let's give you a sample:
The package zope.subscriber (3.5) defines a new subscriber
and zope.catalog (3.5) uses this subscriber. And we have
package zope.folder (3.5) which fires a notify for this
If you will use the new subscriber and it's automaticly
handling you will define that all version must be 3.5.
But t's also possible to use version (3.5) of zope.subscriber
and implement in your custom container implementation the
new subscriber pattern from zope.subscriber (3.5).
The package zope.catalog and zope.folder can still be at
Probably the sample above is not so good. But think about
small zope.* package based distributions and the dependency
to the ZODB package. I'm sure there it is possible to assamble
many different versions of the ZODB egg within different
versions within other zope.* packages. If any of them
defines a version for ZODB, you will get very quickly into
troubles. (You can still apply a patches if you like to use an
older ZODB and if something doesn't fit)
If we need to define versions, then a KGS is the concept which
allows you to define this set. And this means that the versions
defined in eggs are obsolate. I guess Stephan implemented this
If we like to see different Zope 3 based distributions like
Zope 3 itself, Grok or Z3Ext etc, it must be possible to
assamble all the package within different versions of zope.*
packages. And then it doesn't make sense to fix version in
do you know what I mean, was this understandable
or can you give additional hints?
END OF MESSAGE
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -