cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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?
> 

very,

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

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message