Hi Gilles, > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski <gillese...@gmail.com>: > > No; the remark is for making the reviewer's life easier, i.e just copy/paste > the command and see the build succeed. Without the environment variable, > the "javadoc" step fails IIRC.
Ok, thanks for the hint. I didn’t know this. > It's not the procedure. I simply stress FTR that the release notes > become less and less what they should be, that is a summary for > human consumption that attracts the user's attention on functional > changes. [The full set of changes is always accessible through the > commits log.] > To ensure clarity for users, changes that cannot affect them should > not be listed in "changes.xml". Yes. For the sake of clarity for the user, I find the manual maintenance of changes.xml much better than other measures like commit logs or JIRA-Ticket reports. However, I’m a bit hesitant to change entries made by other committers. I guess that would require consent between all committers of a project on how to maintain the changes list. >>> There are a few changes marked incompatible. Is it expected in a minor >>> release? >> The japicmp report recommends a 0.1.0 release which it is. > > I don't understand why, but OK then… Actually, it took several changes to be reverted just to get to this state. >>>>> [ ] +1 Release these artifacts >>>>> [ ] +0 OK, but... >>>>> [ ] -0 OK, but really should fix... >>>>> [ ] -1 I oppose this release because… >> >> Would you please consider voting? > > +1 > > [There are no technical issues, only communication issues that are > common problems with all the releases.] Thanks, Gilles. Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
