Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Wed, 13 Mar 2002 00:14:28 +0000
Subject: Re: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
From: Stuart Roebuck <stuartroebuck@mac.com>
To: cocoon-dev@xml.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <00d601c1ca04$4d293270$0a00a8c0@vgritsenkopc>
Message-Id: <48B42400-3617-11D6-85D7-0030654777A6@mac.com>


On Tuesday, March 12, 2002, at 08:27 pm, Vadim Gritsenko wrote:

>> From: Stuart Roebuck (Telewest) [mailto:stuartroebuck@mac.com]
>>
>> Thanks Vadim,
>>
>> Up until now I've happily gotten away with merging changes to the
>> src/webapp/cocoon.xconf into my own when updating my Cocoon version -
>> it's clear that I should have used the build version of the document
>> which isn't the same thing any more!
>
> And this "any more" is here for a quite a while now:
>
> Wed Jan 16 10:39:22 2002 UTC (7 weeks, 6 days ago) by cziegeler:
>   Added new XConfTool which dynamically adds
>   blocks to the cocoon.xconf. This is similar
>   to the sitemap tool, but less sophisticated...for now
>
> :)

but until a few days ago it still worked as long as you weren't using 
some of the optional code.  Now the cocoon.xconf file in src/ is invalid 
for all uses by default.

>
>> This reminds me - how about having a plaintext "WHATSNEW" file at the
>> CVS root to which everyone appends changes (in reverse date order -
> with
>> clearly titled break lines for releases), listing any changes to
> Cocoon
>> that impact on the configuration, plus anything else that may be of
>> general interest like 'implemented XXX which speeds up Cocoon by a
>> factor of 100'.
>
> This is called "changes.xml". Sample record:
>   <action dev="CZ" type="update">
>     Restructured build system. A new ant task (SitemapToolTask) adds
> entries
>     of optional components to the sitemap. Warnings for not available
>     optional components are printed out.
>   </action>
>
> (I must confess: for second version of XConfTool I did not wrote entry
> to changes.xml, I only sent [ANNOUNCEMENT] email)

Yes, I confess I'd forgotten about the changes.xml file.  It isn't very 
accessible, so I tend to do a cvs2cl on the CVS repository to get the 
same information with the benefit of it being comprehensive, listing all 
source files affected, and providing date information.

I think a human readable (please - no debate on the human readability of 
XML!) file focusing on providing slightly more extensive explanations of 
changes which impact on configuration would be a very valuable part of 
the documentation issues of moving Cocoon into the mainstream.  In fact, 
you could save a bit of work by throwing out changes.xml - and 
generating it automatically with cvs2cl (I think it can output XML - but 
I've never tried it), then using the spare time to keep WHATSNEW up to 
date! ;)

>
>> It would be *extremely* helpful if someone maintaining a Cocoon
>> configuration could work on the basis that an update of Cocoon would
>> work with their existing .xconf and .xmap files unless explicitly
>> indicated in the WHATSNEW file.
>>
>> I don't think this would be hard to maintain, and it would make it
>> easier to construct release notes to encourage interest in the latest
>> and greatest releases.  The Ant project does it quite well.
>
> Isn't current Cocoon's release notes are constructed from the
> changes.xml?
>
> Vadim

            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Systems Architect                             Java, XML, MacOS X, XP, 
etc.
ADOLOS                                           <http://www.adolos.com/>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org