Re: [VOTE] Release Apache Maven Version 3.6.2
+1 On Wed, 28 Aug 2019 21:17:49 +0200, Enrico Olivelli wrote: Hi, We have solved 52 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12345234 There are issues left in JIRA for Maven core: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1529 The distributable binaries and sources can be found here: https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/ Specifically the zip, tarball and source archives can be found here: https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz The release artifacts are staged for distribution in: https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2 Source release checksum(s): apache-maven-3.6.2-src.tar.gz sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade sha512: 235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7 apache-maven-3.6.2-src.zip: sha1: c6c5bd9828b3350905e97177978724eed0698de3 sha512: d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b Git tag: https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117 Staging site: https://maven.apache.org/components/ref/3-LATEST/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Enrico Olivelli - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Draft of release notes for Maven 3.6.2
We have contributors listed directly in the POM https://github.com/apache/maven/blob/master/pom.xml#L120 If we started with this great idea to list contributors in POM, we should continue with it and this is the same privilege for future contributurs as well. They will be listed on the Maven sites which is a big Thx from us ASF/Maven for them. Enrico, you have hard time because you are doing it only by your hands. Why not to ask the contributor to add himself to the POM while the pull-request is open? This would simplify your work with the release and then the release notes is more simple to do. For instance in the JUnit4 group the author and contributor is writing the release notes on Wiki. It is part of the normal work, otherwise it is incomplete. I was also asked by the comitter to describe the fix/feature on Wiki in JUnit4. But there must be writtent rules and culture in the team to remind the contributor to write the release notes. You as committer cannot compete with a large number of contributors! The contributors must understand that the work is not only about Java code, it is also documentation of whatever manner. Also we should ask a contributor whether he wants to be in the list, but we cannot ignore the contributor in the list. And what is the next fact, the list of contributors exists for some time. We should continue in this tradition and we should pickup a new commiter from this list. It is simple because we can see that some contributors are more active than the others and we can see it based on the the number of issues MNG-x. We will very hardly "decompile" the release notes and find such statistics. We can do it only in JIRA. But still "reporter" is important because without him the idea would not exist and this is important for users, I mean the idea, but contributor will be always in the development team or in the users which is the matter of time when somebody writes the code. Contributors are important for development and us in ASF but the reporter is relevant for users because he is the architect of "business idea" - of course it is not the same as in the enterprise. In the enterprise, the customer does not care who is contributor ala developer, he cares about the work done for him. On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli wrote: > 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 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 > > 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- John Doe' doesn't provide me useful > information. > > > The list of 'MNG- 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 b
Re: Draft of release notes for Maven 3.6.2
My 2cts would be that maybe we are mixing things (all points "IMHO" but trying to make them short): 1. Changelog: jira+github driven, must be exhaustive about changes and stay forever with a permalink on the website 2. Release notes: some highlights from the changelog, likely user impacts mainly and if very structural internals (like guice migration some time ago maybe). Can stay linked in 1 on the website. 3. Annoucement: top highlights (#3) + rewards (distincts contributors probably) and standard download stuff. If possible a word on next release if we already know. Can appear on the website in a blog like section but no permanent link is fine too. 1 is trivial to automate but 2 and 3 extract the value from it and add sense to it so is likely a human work until we normalize jira (for 2 at least). This is how I approach that topic from a theorical point of view. Now current proposal making all points collapsed works for me too while info is there and can be found by end users and mojo dev. Just my 2cts indeed Le sam. 31 août 2019 à 13:05, Enrico Olivelli a écrit : > 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 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 > > 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- John Doe' doesn't provide me useful > information. > > > The list of 'MNG- 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 > > > >> > > > >> > > > >> wrote: > > > >> > > > >> > Hi all, > > > >> > I have sent a draft of the release notes for 3.6.2 > > > >> > > > > >> > this is t
Re: Draft of release notes for Maven 3.6.2
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 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 > 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- John Doe' doesn't provide me useful information. > > The list of 'MNG- 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 > > > > > 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 > > > 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 > > >> > > >> > > >> 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 > > > > >
Re: Draft of release notes for Maven 3.6.2
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 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- John Doe' doesn't provide me useful information. > The list of 'MNG- 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 > > 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 > > 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 > >> > >> > >> 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 > >
Re: Draft of release notes for Maven 3.6.2
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- John Doe' doesn't provide me useful information. The list of 'MNG- 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 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 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 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
Re: Draft of release notes for Maven 3.6.2
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 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 > > 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 > >
