cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Proposal: release management guide (was Re: [RT] Versions)
Date Wed, 21 Apr 2004 13:49:35 GMT
Upayavira wrote:

> 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


Mime
View raw message