Yusei TAHARA wrote:
>> Should the old zope.app.* package depend on the new zmi.core package?
>> (I think not)
> No. But zmi.core might depend on zope.app.* packages.
I think this should be avoided if we can. The idea is to lose the
dependency of the zope.app.* packages for the ZMI, after all.
Of course there are exceptions: if you rely on a zope.app.* package that
hasn't really been moved to zope.* yet (zope.app.form.browser for
instance). But relying on zope.app.*.browser should be avoided in most
cases, otherwise we create circular dependencies.
>> Or should we break BBB and let people know that they have to install
>> zmi.core for zmi support? (I think so)
> I won't break BBB as much as possible, at least I'd like to keep persistent
> data compatibility...
But the ZMI is all views, right? What is persistent?
For BBB, you want the zope.app.*.browser packages to import from
zmi.core, not the other way around. Otherwise we don't clean up
dependencies at all.
>> - bump up the zope.app.* package version (full not partial)
>> e.g. 3.5.1 to 3.6.0
> Hmm, I'm not sure yet...
I think this should be done; if you update a zope.app.* package to
import its ZMI stuff from zmi.* a new release of the zope.app.* package
should eventually be made, and it should have a new feature release (so
increase y in x.y.z).
> For now, I don't have clear image yet. I'm checking all zope.app.* packages
> and make
> sure all tests pass. And maybe I will review current package dependencies.
For that, you might want to investigate the z3c.recipe.depgraph recipe
to generate dependency graphs. To try it against trunks you need to add
them to 'develop' in your buildout.cfg
> After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm
> very slow
> for some reasons, I cannot make an exact schedule yet.
I don't think you're slow at all. Your plan sounds good and I'm glad you
have Roger giving you feedback.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -