I have started a rough sketch for a table, showing the modules of Plone, so it is easy to see at once, which components are, will be, or aren't part of the stack anymore, and maybe also quick-notes about known compat-issues, which need pinning of versions, due to changes in the stack (especially when introducing new modules).
Because writing a table in reST makes me nuts, I have created a document on plone.org, everyone with a login, should be able to see and edit it:
Hi Ida,
while I do appreciate the top part of the table which it's quite
comprehensible, I don't understand the bottom part. From the intro and
the title I thought that this wouldhave been a time table..Could you
explain it a little bit?
In the developer helpers, I would never put Grok since nobody seems to
use grok except the ones that write documentation...which kind of sucks.
On the other hand, from the top of my mind, I would add mr.bob just
'cause it seems to be very appreciated.
Hi Giacomo, thanks very much for your response!
The top part shows the minimal-dependencies to get a basic Plone running, the bottom part is supposed to show the introduction/removal of sub- or additional-components, where the timeline basically refers to the release-dates of Plone's major-releases, that's why the CMFPlone-row is marked with bold text, it's supposed to be the axis everything else is spinning around, where top- and bottom-part should reflect the hierachic dependencies.
I want to add another column, to make clearer, which modules are actually a dep of CMFPlone or outside of it (add-on).
As said, this is a rough sketch for the structure, I'm planning to fill it with some meaningful content by the end of the week, fortunately there is a lot of docs for this already (thanks to Alex Clark, also), it just needs to be collected.
Please feel free, to modify the table as you think would be good, f.e. adding mr.bob as a possibility to use, but mark it as an aspirant, for now.
Thanks also for your opinion about Grok, I never used it, unless forced to, and have read a lot of reputated voices by now, to not use it. That's why it could be good, to officially state that and also remove it of the docs. Nevertheless it could be mentioned as optional, for anyone who wants to use it anyway.
If I got it right, it was recommended once and now isn't? Which happens, but needs to be documented (=clearly communicated), I think.
Ok, sanitized the basic-struc and added Archetypes vs Dexterity as an example for the timeline.
Also moved the sketch to GitHub for now, so anyone interested, can fork and edit, and by that, it's was also possible to add a little visual enhancement via js/css: If you type one of the given state-keywords (candidate, stack, deprecated, dropped) into a table-cell as a paragraph, styles will be applied to that paragraph.
Ida