cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: on better release and version management
Date Wed, 24 Sep 2003 18:40:59 GMT
Timothy Larson wrote:
> Maybe we are having a hard time finding the "right" word because we are
> mixing concerns.  I can think of roughly four separate things the user
> of a module would want to know:
> 
>   (1) Is the module stable?
>       (i.e. is it considered to generally work properly with no critical bugs?)
>   (2) Will code written against it will work with future releases?
>       (i.e. will there be a back-compatibility effort made in new releases?)
>   (3) Will there likely be any future versions?
>       (i.e. is there still an active development person or community?)
>   (4) Are they the only guinea pigs actually using the module?
>       (i.e. is there an active user community?)
> 
> On another tack, this information is mostly dynamic:
> 
> While case (1) is usually static, but see the planned cocoon-2.1.1 -> 2.1.2
> release for an example of this being a little dynamic.  For a stronger
> example, think of a crypto module after a security hole is found and
> fixed in a new release.  The old version transitions from stable to condemed.
> 
> Case (2) starts out as only an expression of intent and then transitions
> when a new release is made to being an attribute of the new release that
> reflects back on the release in question.
>  
> Cases (3) and (4) are not direct attributes of the module, but rather are
> attributes of the community that reflect back on the module.
> 
> In all these cases, any meta-info included in a release can only represent
> a snapshot in time.  This is useful, but it would be better if it could be
> combined with live meta-info retrieved from the module's source site upon
> download, to account for reality drift over time.
> 
> <side-note>
> Eventually it would be helpful for the source website to include the static
> meta-info, live meta-info, and some pretty, graphical data from some community
> data miners like Agora, etc. to help evaluate the liveliness of a module and
> its developer and user communities.  This could even be used by the developers
> to help track what is used, what is causing problems, what can be retired, etc.
> </side-note

What about providing this or whatever info is needed (even Stefano's 
original "strawman" proposal that he pointed out is self certifying but 
"sign" the information by an authority.  The "certification" we've been 
discussing would then really "signed" by Cocoon.  Perhaps there could be 
cobs in Cocoon's repository which are not signed, and perhaps there are 
one man shows which are "signed" because they are labeled as such.  The 
"certify"ing is done on the statement of information about the block.

Geoff











Mime
View raw message