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.


- -- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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

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

fn:Andreas Jung
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to