[Zope-dev] why external version indexes don't fulfill all use cases for development

[Jim Fulton]

On Nov 11, 2007, at 6:34 PM, Stephan Richter wrote:

> On Sunday 11 November 2007, Jim Fulton wrote:
>>> This breaks a fundamental assumption for releases. When I release
>>> something, I expect it to work tomorrow, next month, and next year.
>>
>> If you want this, then you can't rely on the KGS.  When releasing our
>> applications, we don't rely on a KGS. We fix all of the versions
>> we're using.  IMO, the KGS shouldn't try to solve this problem.  A
>> KGS should be helpful for developers and development frameworks.  A
>> KGS will be more useful if the quality remains high.   A KGS is
>> similar to a traditional monolithic release.  After all, bug fix Zope
>> releases have been known to break applications too.
>
> I really hope you will use the KGS as a starting point somewhen for  
> your
> internal applications as well. :-) (Note that you can now override  
> versions
> using the new "extends" feature that I shamelessly copied from  
> buildout.)
>
> And I am not saying this to promote the KGS. I have a concrete  
> example.
>
> Probably as part of a project, Benji did some development on  
> zope.testbrowser.
> He fixed the versions of all dependencies in buildout.cfg. However,  
> those
> versions were a version sub-graph of a ZC internal dependency graph  
> that I do
> not have access to. It was also already pretty outdated referring  
> to "dev"
> and "alpha" releases.
>
> So while testbrowser might be working with those dependency  
> versions, it might
> still be broken for me, because I have a totally different  
> dependency graph.
> The worst scenario, which luckily has not happened yet, is that we  
> fix things
> back and forth because of different dependency graphs.
>
> I thus propose that all packages in svn.zope.org should use a KGS  
> for testing,
> because it is a fully public dependency graph. I am not sure  
> whether it
> should be the latest stable KGS or the development KGS or whatever.  
> Time will
> provide an answer.

I think you make a good point.

+1 on using *some* KGS.

Jim

--
Jim Fulton
Zope Corporation