Closed ericof closed 1 month ago
I am not sure about this. This is not how I imagined plone.classicui
until now. Could be okay though.
In the PR you currently add these, in addition to plone.distribution
:
"Products.CMFPlacefulWorkflow",
"plone.app.caching",
"plone.app.discussion",
"plone.app.iterate",
"plone.app.multilingual",
"Products.CMFPlone",
Compared with the Plone
egg, this misses:
plone.volto
, for obvious reasonsplone.restapi
, but that gets pulled in by plone.distribution
plone.app.upgrade
I am inclined to only have Products.CMFPlone
here. Not everyone needs Iterate or CMFPlacefulWorkflow. In 6.1 we have made Multilingual a core add-on on top of CMFPlone, and same is almost finished for Discussion.
Some thoughts:
plone.classicui
(and plone.volto
where I see you are doing the same) are example distributions. They are fine to test Plone. They are fine as a basis for your own project if you are not so experienced with Plone.plone.classicui
, unless you are fine with its choice of add-ons.I guess this is a fine approach as well, just a bit different than I had expected or was planning for.
But then I would say: add plone.app.upgrade
to the install requirements of both plone.classicui
and plone.volto
. This is best for our target audience of inexperienced users. Otherwise the first time they do a bugfix update, they won't be able to run the @@plone-upgrade
steps.
cc @plone/classicui-team
No, that is not the idea to add those here. See my post https://community.plone.org/t/plone-6-1-architecture-and-mental-model/
Having an extra all
or full
would be OK.
inexperienced users
should still install just Plone
.
As it should be possible to install
plone.classicui
instead ofPlone
, we have to make sure all packages listed there are also listed here.