[Zope-dev] the Zope Framework project

[Chris McDonough]

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.

On the other hand, it shouldn't be as difficult as you mention above to
determine which versions of which packages work together:  at least not
difficult enough to require the subcontracting of such work to some committee.
There shouldn't *be* that many things!  If one package is depending on an
implementation detail of another package that isn't spelled out in an interface,
the two packages shouldn't be separate in the first place; they should be a
single package.  If we took this simple idea to heart, I suspect lots of related
packages could be re-collapsed into a single package, making the set of packages
would less giant in the first place and more manageable.

> I agree on the point of making the components having their
> own lifecycle and to make them usable more independently.

Cool.

- C