Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <20030924183445.68213.qmail@web41902.mail.yahoo.com>
Date: Wed, 24 Sep 2003 11:34:45 -0700 (PDT)
From: Timothy Larson <timlarsonwork@yahoo.com>
Subject: Re: on better release and version management
To: dev@cocoon.apache.org
In-Reply-To: <776E9EB0-EEAE-11D7-AD24-000393D2CB02@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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>

--Tim Larson


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com