...So we have following lifecycle states:
- contributed - supported - deprecated blocks.
+1
...The "verified" status could be orthogonal to these lifecycle-states and is an indicator of a (to be definded) block's quality (tested, stable interfaces, stable implementation, supported by community, ...)..
+1
Addtionally I like Betrands idea (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) of a narrative status description:...
/me has no memory but the archives do ;-)
..."Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."
I think we should provide some structure by providing a template that has some mandatory parts and a free text part...
+1. One of the mandatory parts should be "automated tests coverage".
...I propose to reflect these lifecycle-states in our SVN directory structure. Additionally we should add the directories "samples" and "core".
/cocoon/blocks/contributed /cocoon/blocks/supported /cocoon/blocks/deprecated /cocoon/blocks/core /cocoon/blocks/samples
+1
...For now I propose to put mini-apps into "contributed", "supported" or "deprecated" and if we get swamped with "mini-apps" we can find another solution if it is necessary...
good enough, +1
WDOT?
Thanks for digging up this info, I'm all +1s as you can see, this looks good!
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
