Hello. Le lun. 17 janv. 2022 à 13:33, Thomas Vandahl <t...@apache.org> a écrit : > > Hi Gilles, > > > Am 14.01.2022 um 15:37 schrieb Gilles Sadowski <gillese...@gmail.com>: > > > >>> Maven artifacts are here: > >>> > >>> https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ > > > > I only see one ".pom" file and one ".xml" file (with their respective > > crypto sig). > > > … and modules below > https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3
Actually they _above_ link, hence my confusion! One has to click on "Parent Directory" with target https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/ in order to see the modules. > > > We should note that this command requires the environment variable > > JAVA_HOME > > to be set (otherwise the build will fail). > > > Is this a special requirement of this build? 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. > If so, why? > > > Shall we stop cluttering what should be a summary of important changes, > > easily readable by a human, with bot-generated messages and trivial > > one-liners like "isEmpty()"? > > > I followed the directions for the release preparation at > https://commons.apache.org/releases/prepare.html and generated the release > notes with „mvn changes:announcement-generate -Prelease-notes“ and the vote > e-mail with „mvn commons-release:vote-txt“ as recommended. What is wrong with > this procedure? 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". > > > Is the Log4j2 version update related to the latest security issue? > > If so, that may have been important to note. > Actually, no. log4j is an optional dependency. > > > Nit-pick: Rather than tagging them with "IMPORTANT CHANGE", it would > > be clearer that important changes are mentioned in the description, at the > > top of the release notes. > This *is* part of the description. You cannot tag changes in changes.xml. I > remember discussions about making releasing easier. Every *manual* step such > as writing release notes does not follow this direction, IMO. My opinion is that the release notes are essentially a "manual" step (even though we get help from a tool that formats the contents of "changes.xml") in the sense that the developers "talk" to the users and tell them why they should upgrade. So I think that important changes should be mentioned, if just with a sentence like "There are important changes, please read through the list below" (and that's why the list should not be cluttered with trivial changes). > > > 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... > > >>> [ ] +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.] Best regards, Gilles > > Bye, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
