[Zope-dev] the Zope Framework project

[Andreas Jung]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04.03.2009 8:50 Uhr, Chris McDonough wrote:
> Andreas Jung wrote:
> 
>>> 2) I'm also not in favor of a giant lockstep set of software versions shared
>>> between notional releases Zope 3.5, Grok, and Zope 2.12.  I can only see this as
>>> continuing our mistakes of old by trying to treat some collection of software as
>>> "Zope" as opposed to letting parts of it survive or die on their own based on
>>> merit; it'd be more effective to just let each framework use (or disuse!)
>>> whatever versions of stuff that work best for it.  That's why the software is
>>> broken out into individual components in the first place; we should encourage
>>> diversity in component usage.  Instead of trying to legislate and bless some set
>>> of components as a "version", we should just work to make each piece better and
>>> worthwhile to use independently; it's value would be in its actual usefulness
>>> rather than some belief that it works well with the other components in the
>>> "version".  Could we at least agree that lockstep versioning of a huge set of
>>> Zope eggs to be shared across many frameworks is not optimal for the long term
>>> and that it would be better if each framework could pick and choose whatever
>>> components and versions it actually needed?  Could we also agree that this would
>>> tend to result in better dependency partitioning ("X depends on Y, I don't need
>>> Y, I just need X, let's fix that")?
>>
>> A central maintained KGS for Zope 3.X components is necessary since only
>> a minor number of core developers knows exactly which version match
>> together. You can not expect that non-core developers have this
>> knowledge. 
> 
> In places that require cross-package API contracts, each contract should be
> spelled out in an interface.  If each contract is spelled out in an interface,
> non-core developers should have no problem gaining this knowledge.  That's what
> interfaces are for.

Interfaces are one side of the medal, the other side are dependencies
expressed through version pinning. We have had enough examples with
version conflict with modules that would obviously fit together based
on their interface definitions. That's where a KGS helps a lot - however
this is not a contradiction to the approach that Tres pointed out with
maintaining a per-project index with hand-selected packages. I find this
idea very compelling for a bunch of usecases - not sure if this a
general approach - one out of many.

Andreas

- -- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
- ------------------------------------------------------------------------
E-Publishing, Python, Zope & Plone development, Consulting

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmuOPAACgkQCJIWIbr9KYwOjQCgt9O7I4qdRBlzqsm93OfzYBf2
VYQAoII60shD+EkPF9TqaTb5ZaQQ3rDT
=DrbH
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090304/a5a7f515/attachment-0001.vcf