cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Proposal: release management guide (was Re: [RT] Versions)
Date Wed, 21 Apr 2004 11:36:58 GMT

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?


I would even suggest (already) that blocks in state 'stable' would 
maintain an own release numbering scheme which complies to these rules.

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message