The plone.app.tiles package c.cover is depending on (1.0.1) has a nasty recursion problem in the GenericSetup Profile: it depends on itself in the metadata.xml dependency.
This causes for example ftw.upgrade to (sometimes) detect a profile dependency infite loop, which disables most of ftw.upgrade in a site where collective.cover is available. This metadata.xml snafoo has been already been fixed in plone.app.tiles 2.X
If that's too big a change, should / could we ask for a plone.app.tiles 1.0.2 that at least removes just this line ? @datakurre There's no 1.X maintenance branch for plone.app.tiles . Is it worth the effort or can we help with getting plone.app.tiles 2.X backwards compatible with 1.X so we can upgrade to that ?
The plone.app.tiles package c.cover is depending on (1.0.1) has a nasty recursion problem in the GenericSetup Profile: it depends on itself in the metadata.xml dependency.
This causes for example ftw.upgrade to (sometimes) detect a profile dependency infite loop, which disables most of ftw.upgrade in a site where collective.cover is available. This metadata.xml snafoo has been already been fixed in plone.app.tiles 2.X
According to https://github.com/collective/collective.cover/pull/516 however (where plone.app.blocks is upgrades to 2.X) plone.app.tiles 2.X has backwards incompatible changes.
If that's too big a change, should / could we ask for a plone.app.tiles 1.0.2 that at least removes just this line ? @datakurre There's no 1.X maintenance branch for plone.app.tiles . Is it worth the effort or can we help with getting plone.app.tiles 2.X backwards compatible with 1.X so we can upgrade to that ?
(Moved here from https://github.com/collective/collective.cover/issues/623)
CC @fredvd @datakurre @mauritsvanrees