Would it be worth starting with a list of commit one liners then release manager (or whom even) edits for more readability?
Is a ticket to track resolution of the time issue needed if not already raised to ensure this does get resolved at some point in the future whether it be environment or build changes or documentation changes? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On January 17, 2022 at 8:39:31 AM CST, Thomas Vandahl <t...@apache.org > (mailto:t...@apache.org)> wrote: > Hi Gilles, > > > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski <gillese...@gmail.com > > (mailto: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 > (mailto:dev-unsubscr...@commons.apache.org) > For additional commands, e-mail: dev-h...@commons.apache.org > (mailto:dev-h...@commons.apache.org) >
