Stephan Richter wrote:
> On Monday 02 March 2009, Hanno Schlichting wrote:
>> 2. Split the Zope 3 KGS into two parts: the Zope Framework bits and the
>> Zope 3 Application Server bits.
> I prefer (2) as I told Martijn in a review of an early draft of the proposal. 
> I would also sign up for the implementation of the split.

I took your comments into account. To quote from the document:

As a service to the users of the Zope Framework, the Zope developers
also make available lists of version numbers of core libraries that
have been tested to work together as a "Known Good Set". This receives
a version number and is the Zope Framework release.  Users of the Zope
framework can use this list, but may also diverge from it where they
see fit. Other projects (such as the Zope 3 application server and the
Grok project) also have a Known Good Sets that expand on the Zope
framework list (and may diverge from it). Each of these consumer
projects can of course have their own release process, schedule and
version numbering.

The KGS concept may be expanded beyond this point to help convey more
information about the libraries such as deprecation status.

Above we described the concept of a Known Good Set for a collection of
libraries (or framework). We have currently technical infrastructure
that was developed to maintain the KGS for the traditional "Zope 3"
system. We will need to adjust the technical infrastructure to also
support a KGS for the "Zope Framework" itself, so we can separate it
from the KGS for the app server. This means the KGS infrastructure
will be usable for more than a single project, and this means other
projects may choose to start using this infrastructure as well.

I think the Zope Framework should start with any library that's required 
to make things like Zope 2 and Grok and the Zope 3 app server work. We 
should then whittle it down over time. We don't have to solve the goal 
of having a more manageable framework with less libraries in it right 
away, we just need to define the goal and continue making progress.

Perhaps that idea provides unwieldy, and we could define more levels 
than just "core" and "extra", for instance "core", "coreplus", and 
"extra", where "coreplus" is an extension of "core" needed to support 
Zope 2. "coreplus" would be a legacy list though and we should have the 
goal to get rid of it. I think we should start with a broad "core" 
however and get rid of stuff over time, instead of providing a core that 
nobody really uses right now.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to