My only concern with (2) is that the list is generated dynamically and if the service goes away, so does the list.
Maven does support generating CHANGES files from JIRA on release, I would advice we make updating the CHANGES file part of the release process and implement the maven plugin to create it. Mark On Fri, Nov 19, 2010 at 11:17 AM, Sands Alden Fish <[email protected]> wrote: > +1 on #2. It'd be nice to have some connection remain between the code you > check out and the related documentation. I suppose you could also add in a > list of the major feature additions for the current release there, but I > imagine you could just learn that from getting to the wiki/JIRA. > > -- > sands fish > Senior Software Engineer > MIT Libraries > Technology Research & Development > [email protected] > E25-131 > > > > > On Nov 18, 2010, at 11:31 AM, Tim Donohue [email protected] wrote: > > All, > > As we now are tracking all issues via JIRA and are going to be releasing > our Documentation via Confluence (which integrates well with JIRA), I'm > beginning to wonder whether we need to continue to maintain a CHANGES > file in SVN: > > http://scm.dspace.org/svn/repo/dspace/trunk/dspace/CHANGES > > In preparation for 1.7.0 release, I've recently updated our new > "History" page in our Wiki Docs to automatically query for all 1.7.0 > fixed issues in JIRA. This essentially provides a very similar list to > what we have been maintaining in the CHANGES file. But, now it is > automated, based on JIRA issues which are closed/resolved for 1.7.0: > > https://wiki.duraspace.org/display/DSDOC/History > > So, I thought I'd ask to see if anyone feels strongly about continuing > to maintain the CHANGES file. There are a few options going forward: > (1) Continue to maintain CHANGES file in parallel to this new History page. > (2) Keep the CHANGES file in SVN, but replace all its contents with just > a link to 'History' page in the Wiki Documentation. > (3) Remove the CHANGES file from SVN entirely, as the changes/history > are now tracked automatically in the Wiki docs. > > I am beginning to lean more and more towards #2. But, if others feel > strongly about continuing to maintain the CHANGES file, we can do so. > > What do you think? > > - Tim > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- Mark R. Diggory @mire - www.atmire.com 533 2nd Street - Encinitas, CA 92024 - USA Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
