cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: Proposal: release management guide (was Re: [RT] Versions)
Date Wed, 21 Apr 2004 12:19:55 GMT
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



Mime
View raw message