Hi Martijn
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 solve. 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 by itself. 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 do not. 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 subscriber. 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 version 3.4. 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 feature yesterday. Fazit, 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 packages, right? Stephan, do you know what I mean, was this understandable or can you give additional hints? Regards Roger Ineichen _____________________________ END OF MESSAGE
Regards,
Martijn