Marc Portier wrote:
Upayavira wrote:
Carsten,
Reads very well, I say. All we need to do is decide if that is how we actually want to (and can) work!
One addition is to mention our policy on blocks and block status:
Blocks and Block Stability
--------------------------
Cocoon currently allows optional functionality to be included or excluded using a simple system called blocks, in which the functionality is included or excluded at compile time.
[NB. This is a precursor to a more complete block system which is currently under development.]
A block can have one of three statuses: unstable, stable or deprecated. An unstable block has an API that can change without
notice. A stable block is subject to the same versioning process
as described in this document. Similarly, when the entire functionality of a block is deprecated, it will be handled in
the same way as any other deprecated code within Cocoon.
=========================
Does this seem reasonable?
very,
I would even suggest (already) that blocks in state 'stable' would maintain an own release numbering scheme which complies to these rules.
I thought about this. But, given that they will be released as a part of Cocoon, I cannot see how that would work. Unless they are released as separate packages that happen independently, they'll need to follow Cocoon's versioning system, IMO.
Regards, Upayavira
I think so too and IIRC this was also the conclusion of a discussion about the lifecylce of _real_ blocks.
-- Reinhard
