>> 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
