AW: [Zope-dev] why external version indexes don't fulfill all use casesfor development

[Roger Ineichen]

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