Stephan Richter wrote: > On Monday 02 March 2009, Hanno Schlichting wrote: [snip] >> 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. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
