I think jira should remain the consolidated list of bugs fixed during a release. Having it on the site is important, but specifically I don't want to have yet another file to update each time i fix a bug. Grabbing the release notes from jira and updating the site is nice and efficient and pretty error proof.
On Fri, Jul 10, 2009 at 11:34 AM, Jesse McConnell<jesse.mcconn...@gmail.com> wrote: >>> 2) see commits in site branch. >>> >>> The basic approach is this: >>> >>> * push all release notes into docs/$version/release-notes.html instead of >>> the consolidated older format and add a page to list them in order >>> >> >> So if someone wants to see the historical list of changes they will need to >> look at N documents? The consolidated format is good as the history of >> change is kept in one place which is what people looking to migrate want to >> see. > > we struggle with this for jetty as well...historically we have a > VERSIONS.txt file in the root of the project that is incrementally > updated with each resolves bugzilla or jira issue. I don't think we > would want to split this up on a per release basis as it allows folks > who are upgrading from a few versions behind one location to look to > see all of the resolves issues since their version. > > managing that consolidated file is a pain though as it seems silly to > pass it around as a resource inside of an assembly to broker it around > the build and the top of the build is the best place to keep the > file... > > anyway, doesn't strictly apply but I agree with jason on the value of > a consolidated release notes file > > cheers, > jesse > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
