[Zope-dev] ZTK 2.0 process

[Hanno Schlichting]

On Tue, Feb 26, 2013 at 6:12 PM, Stephan Richter
<stephan.richter at gmail.com> wrote:
> Could you outline what the first step would be to create an alpha release list
> for 2.0? We could manually include an sdist of the ZODB 4 py3 branch to make
> the tests pass under Python 3.

I'll have to look at the procedure again a bit. Will do so in the next
days and start updating svn.zope.org/repos/main/zopetoolkit/trunk

>> - Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1)
>
> Some of the zope.app packages (the ones not deprecated) should stay or simply
> be renamed to not being called zope.app.*.

Our rule for inclusion in the ZTK is: Whatever library is used by at
least two out of the three frameworks (BlueBream, Grok, Zope).

Given that BlueBream hasn't seen any release beyond a 1.0 about two
years back, I'm not sure it's active or relevant anymore. Grok isn't
seeing frequent releases, but there was a 1.5.5 mid last year.

If you compare the version list from the last ZTK 1.1.5
(http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg)
and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg),
you'll notice that Grok already overwrites the version requirement for
half of the non-deprecated packages with its own versions. And as I
said, Zope isn't using any of them anymore for a long time.

So I don't see any value in testing and promising stability for those
zope.app packages, when there aren't any shared consumers for the
specific versions.

And the actually used versions by Grok are:
zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug -
renaming those to a non zope.app prefix doesn't make a lot of sense
for me either - as they are all about a specific app server
configuration and not generally reusable libraries.

Hanno