In my opinion release notes should tell: - new features/news and noteworthy - user visible changes - breaking changes
I would add a list of contributors. The list of 'reporters' is not useful. I see we are doing those lists in order to have a better engagement with the community, but I am not sure at 100% it is something that should stay forever on the website, maybe it can be in the announcement email. I have used the release notes of 3.6.1 as template, to me it is not a problem to shrink the list making some sort of select 'distict(reportername)', distinct(contributor name). Enrico Il sab 31 ago 2019, 11:17 Tibor Digana <tibordig...@apache.org> ha scritto: > For me and many users the Release Note like this are very hard to read and > hard to find what is needed. > Many times they go to google because it's easier to search than walking > through all versions of release notes. > > We do not have a cumulative documentation with a list of features and we > often point to release notes whenever any uaser is asking about feature or > for a problem that he has in his build. > > If it was only up to me, I would have the cumulative documentation(s) which > is in one folder, and another documents would be Jira Report generated by > "reporting" and this would include the author in the table - easy and > automated. > IMO it should be just like in the plugins - every feature fully documented > in src/site/../*.apt and pushed with the code and tests to master in one > commit. > > Then the Release Notes would be a matter of command line "mvn site ...". > > On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte <rfscho...@apache.org> > wrote: > > > The goal of release notes is that they are being read. > > There should be a good balance of the amount of information, preventing > > people to say TLDR; > > > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful information. > > The list of 'MNG-NNNN A good JIRA title' is useful and visiting the > > related Jira page will provide you the extra information, including the > > actual reporter and contributors. > > > > Summing up a list of names that helped on the release is a good way to > > appreciate their help on this release. > > > > Robert > > > > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <tibordig...@apache.org > > > > > > wrote: > > > > > We should use authors of the issue/PR/idea. > > > After the release we can ask WHY (practical goals) he wanted the > feature > > > more than how. The question for "HOW" has to be placed very early > during > > > the review, but too late after the PR has been merged. > > > I expect that the reviewer developer has checked all the code, so there > > > would not be questions about *how* it is done. If the reviewer does not > > > understand the code and he admits the change, then it is question for > him > > > whenever a new trouble happens. > > > So this is my opinion - listing the author(s) of the idea in every > > > issue/PR. > > > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <rfscho...@apache.org> > > > wrote: > > > > > >> Not sure if the reader of the release notes is helped with a long list > > >> of > > >> reporters and contributers per issue. > > >> I would expect that only a list of (unique) names is good enough. > > >> > > >> If there is someone that deserves extra credits, I'd say it is Stefan > > >> Oehme for diving into the code, looking for memory leaks AND providing > > >> patches to solve it. > > >> > > >> thanks for pushing this release! > > >> Robert > > >> > > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli > > >> <eolive...@gmail.com> > > >> > > >> wrote: > > >> > > >> > Hi all, > > >> > I have sent a draft of the release notes for 3.6.2 > > >> > > > >> > this is the PR > > >> > https://github.com/apache/maven-site/pull/99/files > > >> > > > >> > Feel free to add comments or push fixes directly to the branch. > > >> > > > >> > It still lacks a bit of formatting, but the content is ready > > >> > > > >> > Cheers > > >> > Enrico > > >> > > >> --------------------------------------------------------------------- > > >> 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 > > > > >
