Re: Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
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 (mailto:t...@apache.org)> wrote: > Hi Gilles, > > > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski > (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) >
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski : > > 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
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 17.01.2022 um 14:11 schrieb Gilles Sadowski : > > 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
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hello. Le lun. 17 janv. 2022 à 13:33, Thomas Vandahl a écrit : > > Hi Gilles, > > > Am 14.01.2022 um 15:37 schrieb Gilles Sadowski : > > > >>> 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
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Gilles, > Am 14.01.2022 um 15:37 schrieb Gilles Sadowski : > >>> 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 > 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? 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? > 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. > 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. >>> [ ] +1 Release these artifacts >>> [ ] +0 OK, but... >>> [ ] -0 OK, but really should fix... >>> [ ] -1 I oppose this release because… Would you please consider voting? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hello. Le ven. 7 janv. 2022 à 19:49, Thomas Vandahl a écrit : > > Hi folks, > > could I please have one more PMC vote? If you think that the outputTimestamp > issue must be fixed before, then please vote -1 explicitly. > > Bye, Thomas > > > Am 03.01.2022 um 18:24 schrieb Thomas Vandahl : > > > > Hi folks, > > > > We have fixed quite a few bugs and added some significant enhancements > > since Apache Commons JCS 3.0 was released, so I would like to release > > Apache Commons JCS 3.1. > > > > Note that, although the core library of Log4j is an optional dependency to > > commons-jcs, we have addressed CVE-2021-44228 by updating log4j-api and > > log4j-core to version 2.17.1. > > > > Apache Commons JCS 3.1 rc2 is available for review here: > >https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2 (svn revision > > 51880) > > > > The Git tag commons-jcs3-3.1-rc2 commit for this RC is > > 5cd1ad02a8ddd196c9594fbb208d708440f87734 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=5cd1ad02a8ddd196c9594fbb208d708440f87734 > > You may checkout this tag using: > >git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > > commons-jcs3-3.1-rc2 commons-jcs3-3.1-rc2 > > > > 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). > > > > These are the distribution artifacts and their hashes: > > > > commons-jcs3-dist-3.1-bin.tar.gz > > 2d64ec75177934524353adcc7cccb92b05b4a5b6014f75b10f16dae2265954da0c0f4c0eb68013fee71d4ec53a49b02f7689de5fce6ff34ae90cd83705a56362 > > commons-jcs3-dist-3.1-bin.zip > > cba57f84ce1e0654239b0ea72663c166e47cf582c0ffc4a2743fd583d35eabbbcb03576fb1aac3e425a48a5b55068c554ab13b3b210a4d50151f62fa9e79894c > > commons-jcs3-dist-3.1-src.tar.gz > > d76daa3e8449e711e91e3f3ec73dc00b212d10db28f0f9a726c4df35bb9578cc1649ee8c5f20159f8cda0f58c569fa5821c3736a3f65fc03cfff74da200b790d > > commons-jcs3-dist-3.1-src.zip > > 1990533137ca75dbbfa702bb8dedb680e2f6d96d301cf263794d96da845c2c72072c1e84b6e50b7dd0588f96fd9512be0d7a61cd08463f1e01044a55a75b0ed5 I'd suggest (again) that we agree on simplifying this step, by having the RM uploading a script that would * download the distribution artefacts from the "dist" area * download a checksum "file" (with the above 4 lines) so that the reviewer can run $ sha512sum -c file > > > > I have tested this with ***'mvn clean verify site site:stage'*** using: We should note that this command requires the environment variable JAVA_HOME to be set (otherwise the build will fail). > > > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: > > /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre > > Default locale: de_DE, platform encoding: UTF-8 > > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" Two successful builds with: (1) Apache Maven 3.6.0 Maven home: /usr/share/maven Java version: 1.8.0_302, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.19.0-17-amd64", arch: "amd64", family: "unix" (2) Apache Maven 3.6.0 Maven home: /usr/share/maven Java version: 11.0.11, vendor: Debian, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.19.0-17-amd64", arch: "amd64", family: "unix" > > > > Details of changes since 3.0 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/RELEASE-NOTES.txt 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()"? Is the Log4j2 version update related to the latest security issue? If so, that may have been important to note. There is a typo: "It is intend to speed up" -> "It is intended to speed up" IMHO, the sentence: "JCS 3.0 and onwards now targets Java 8.0, making use of features that arrived with Java 8.0 such as lambdas." does not really belong to release notes. [And "Java 8.0" -> "Java 8".] 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. As per recent exchanges on the "security-discuss" ML, we might want that the release notes (of all components) contain a reminder of the policy regarding the report of vulnerability issues. > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/index.html > >(note some *relative* links are broken and the 3.1 directories are not > > yet created -
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi folks, could I please have one more PMC vote? If you think that the outputTimestamp issue must be fixed before, then please vote -1 explicitly. Bye, Thomas > Am 03.01.2022 um 18:24 schrieb Thomas Vandahl : > > Hi folks, > > We have fixed quite a few bugs and added some significant enhancements since > Apache Commons JCS 3.0 was released, so I would like to release Apache > Commons JCS 3.1. > > Note that, although the core library of Log4j is an optional dependency to > commons-jcs, we have addressed CVE-2021-44228 by updating log4j-api and > log4j-core to version 2.17.1. > > Apache Commons JCS 3.1 rc2 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2 (svn revision > 51880) > > The Git tag commons-jcs3-3.1-rc2 commit for this RC is > 5cd1ad02a8ddd196c9594fbb208d708440f87734 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=5cd1ad02a8ddd196c9594fbb208d708440f87734 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch > commons-jcs3-3.1-rc2 commons-jcs3-3.1-rc2 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ > > These are the distribution artifacts and their hashes: > > commons-jcs3-dist-3.1-bin.tar.gz > 2d64ec75177934524353adcc7cccb92b05b4a5b6014f75b10f16dae2265954da0c0f4c0eb68013fee71d4ec53a49b02f7689de5fce6ff34ae90cd83705a56362 > commons-jcs3-dist-3.1-bin.zip > cba57f84ce1e0654239b0ea72663c166e47cf582c0ffc4a2743fd583d35eabbbcb03576fb1aac3e425a48a5b55068c554ab13b3b210a4d50151f62fa9e79894c > commons-jcs3-dist-3.1-src.tar.gz > d76daa3e8449e711e91e3f3ec73dc00b212d10db28f0f9a726c4df35bb9578cc1649ee8c5f20159f8cda0f58c569fa5821c3736a3f65fc03cfff74da200b790d > commons-jcs3-dist-3.1-src.zip > 1990533137ca75dbbfa702bb8dedb680e2f6d96d301cf263794d96da845c2c72072c1e84b6e50b7dd0588f96fd9512be0d7a61cd08463f1e01044a55a75b0ed5 > > I have tested this with ***'mvn clean verify site site:stage'*** using: > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre > Default locale: de_DE, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" > > Details of changes since 3.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/changes-report.html > > Site: >https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/index.html >(note some *relative* links are broken and the 3.1 directories are not yet > created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 3.0): > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/rat-report.html > > KEYS: > https://www.apache.org/dist/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner that 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Thomas Vandahl (tv), > Release Manager (using key 88817402) > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Thomas, Actually, I think we can just modify those bin/zip assembly files to include the NOTICE from the project, as is done in [TEXT]: https://github.com/apache/commons-text/blob/5afc42360c077feb50f64dd702ca5b8a3b09c590/src/assembly/bin.xml#L25-L31 And then set an output directory in the assembly part for the maven shared resources (I think that's coming from an older version of JCS that's somehow referenced in the build?). But changing those assembly files should give us the right release files. Unfortunately I have no experience with reproducible builds in Maven, so probably won't be of much help with the other thread. -Bruno On Thursday, 6 January 2022, 10:30:44 pm NZDT, Thomas Vandahl wrote: Hi Bruno, > Am 05.01.2022 um 21:59 schrieb Bruno P. Kinoshita > : > > Did you have an old NOTICE file in the directory where you built the jcs > release? I read the release instructions [1] and the code of > commons-release-plugin [2], and found nothing that appeared to replace files > or dates. The tag on GitHub is showing NOTICE.txt (with the extension) with > the correct dates. No, I haven’t. I completely rely on the files automatically generated by the plugin. If you look at the code of the plugin, you see the mentioned outputTimestamp property is being used. I found docs about this here: https://maven.apache.org/guides/mini/guide-reproducible-builds.html > Maybe somebody else knows how that can happen. The effective POM shows the following entry: 2020-01-22T15:10:15Z Now we see why the year number in NOTICE is wrong. But who sets this? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Thomas, Saw your other thread about the reproducible builds. Really interesting. I found something else, pertinent to this thread, so posting it here. I was dumbfound with that 2020, so I opened both the NOTICE.txt from the GitHub tag, and the one from the zip bin dist archive, one on each monitor, and reading it noticed a difference. The one in the ZIP/tar.gz files has the ":: Distribution" suffix. Looking at the jcs-dist Maven module, it has this following line in the assembly files: https://github.com/apache/commons-jcs/blob/7e38d3342dfd96b8078fd9ca60ff3a43d539df4f/commons-jcs-dist/src/assembly/bin.xml#L57 If you run this command `mvn clean package -Prelease -DskipTests` on your branch, and once it has completed, open ./target/maven-shared-archive-resources/META-INF/, there you should find the NOTICE file with the wrong dates. Now... how that file got there... still not clear to me. -Bruno On Thursday, 6 January 2022, 10:30:44 pm NZDT, Thomas Vandahl wrote: Hi Bruno, > Am 05.01.2022 um 21:59 schrieb Bruno P. Kinoshita > : > > Did you have an old NOTICE file in the directory where you built the jcs > release? I read the release instructions [1] and the code of > commons-release-plugin [2], and found nothing that appeared to replace files > or dates. The tag on GitHub is showing NOTICE.txt (with the extension) with > the correct dates. No, I haven’t. I completely rely on the files automatically generated by the plugin. If you look at the code of the plugin, you see the mentioned outputTimestamp property is being used. I found docs about this here: https://maven.apache.org/guides/mini/guide-reproducible-builds.html > Maybe somebody else knows how that can happen. The effective POM shows the following entry: 2020-01-22T15:10:15Z Now we see why the year number in NOTICE is wrong. But who sets this? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] project.build.outputTimestamp set in org.apache:apache, was Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi folks, This may be of general interest, at least I had no idea about the consequences. So I thought I’d share the result of my research. > Am 06.01.2022 um 10:30 schrieb Thomas Vandahl : > >> Maybe somebody else knows how that can happen. > The effective POM shows the following entry: > 2020-01-22T15:10:15Z > > Now we see why the year number in NOTICE is wrong. But who sets this? Found it. For the information of all interested parties, the following command mvn org.apache.maven.plugins:maven-help-plugin:3.2.0:effective-pom -Dverbose=true produces the line (among others) 2020-01-22T15:10:15Z
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Bruno, > Am 05.01.2022 um 21:59 schrieb Bruno P. Kinoshita > : > > Did you have an old NOTICE file in the directory where you built the jcs > release? I read the release instructions [1] and the code of > commons-release-plugin [2], and found nothing that appeared to replace files > or dates. The tag on GitHub is showing NOTICE.txt (with the extension) with > the correct dates. No, I haven’t. I completely rely on the files automatically generated by the plugin. If you look at the code of the plugin, you see the mentioned outputTimestamp property is being used. I found docs about this here: https://maven.apache.org/guides/mini/guide-reproducible-builds.html > Maybe somebody else knows how that can happen. The effective POM shows the following entry: 2020-01-22T15:10:15Z Now we see why the year number in NOTICE is wrong. But who sets this? Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Did you have an old NOTICE file in the directory where you built the jcs
release? I read the release instructions [1] and the code of
commons-release-plugin [2], and found nothing that appeared to replace files or
dates. The tag on GitHub is showing NOTICE.txt (with the extension) with the
correct dates.
Maybe somebody else knows how that can happen.
-Bruno
[1] https://commons.apache.org/releases/prepare.html
[2]
https://github.com/apache/commons-release-plugin/tree/966cb151acba3939e90a0572df3a03de7ad6ed16/src/assembly
On Thursday, 6 January 2022, 12:25:20 am NZDT, Thomas Vandahl
wrote:
Hi Bruno,
> Am 05.01.2022 um 06:41 schrieb Bruno P. Kinoshita
> :
>
> I didn't have much time, so inspected only one file, randomly selected, from
> the dist area. The src zip. @Thomas, I think the NOTICE has the date 2020? I
> think that can be fixed later? Everything else looks OK in that file.
This is what the maven-remote-resources-plugin puts out, probably based on
${project.build.outputTimestamp}. No idea where it comes from and who sets this.
Anyone?
Bye, Thomas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
Hi Bruno,
> Am 05.01.2022 um 06:41 schrieb Bruno P. Kinoshita
> :
>
> I didn't have much time, so inspected only one file, randomly selected, from
> the dist area. The src zip. @Thomas, I think the NOTICE has the date 2020? I
> think that can be fixed later? Everything else looks OK in that file.
This is what the maven-remote-resources-plugin puts out, probably based on
${project.build.outputTimestamp}. No idea where it comes from and who sets this.
Anyone?
Bye, Thomas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
[x] +1 Release these artifacts Build passed with no issues on my environment with `mvn clean test install site` Apache Maven 3.8.2 (ea98e05a04480131370aa0c110b8c54cf726c06f) Maven home: /opt/apache-maven-3.8.2 Java version: 11.0.13, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-91-generic", arch: "amd64", family: "unix" I didn't have much time, so inspected only one file, randomly selected, from the dist area. The src zip. @Thomas, I think the NOTICE has the date 2020? I think that can be fixed later? Everything else looks OK in that file. Reports look OK, -cache has low coverage, but no idea whether it's easy/doable to write tests for that module. https://commons.apache.org/proper/commons-jcs/commons-jcs3-jcache/jacoco/index.html Thanks! -Bruno On Tuesday, 4 January 2022, 06:24:47 am NZDT, Thomas Vandahl wrote: Hi folks, We have fixed quite a few bugs and added some significant enhancements since Apache Commons JCS 3.0 was released, so I would like to release Apache Commons JCS 3.1. Note that, although the core library of Log4j is an optional dependency to commons-jcs, we have addressed CVE-2021-44228 by updating log4j-api and log4j-core to version 2.17.1. Apache Commons JCS 3.1 rc2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2 (svn revision 51880) The Git tag commons-jcs3-3.1-rc2 commit for this RC is 5cd1ad02a8ddd196c9594fbb208d708440f87734 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-jcs.git;a=commit;h=5cd1ad02a8ddd196c9594fbb208d708440f87734 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-jcs.git --branch commons-jcs3-3.1-rc2 commons-jcs3-3.1-rc2 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1576/org/apache/commons/commons-jcs3/3.1/ These are the distribution artifacts and their hashes: commons-jcs3-dist-3.1-bin.tar.gz 2d64ec75177934524353adcc7cccb92b05b4a5b6014f75b10f16dae2265954da0c0f4c0eb68013fee71d4ec53a49b02f7689de5fce6ff34ae90cd83705a56362 commons-jcs3-dist-3.1-bin.zip cba57f84ce1e0654239b0ea72663c166e47cf582c0ffc4a2743fd583d35eabbbcb03576fb1aac3e425a48a5b55068c554ab13b3b210a4d50151f62fa9e79894c commons-jcs3-dist-3.1-src.tar.gz d76daa3e8449e711e91e3f3ec73dc00b212d10db28f0f9a726c4df35bb9578cc1649ee8c5f20159f8cda0f58c569fa5821c3736a3f65fc03cfff74da200b790d commons-jcs3-dist-3.1-src.zip 1990533137ca75dbbfa702bb8dedb680e2f6d96d301cf263794d96da845c2c72072c1e84b6e50b7dd0588f96fd9512be0d7a61cd08463f1e01044a55a75b0ed5 I have tested this with ***'mvn clean verify site site:stage'*** using: Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Java version: 1.8.0_311, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_311.jdk/Contents/Home/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" Details of changes since 3.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/index.html (note some *relative* links are broken and the 3.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 3.0): https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/jcs/3.1-rc2/site/commons-jcs3-core/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Thomas Vandahl (tv), Release Manager (using key 88817402) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons JCS 3.1 based on rc2
> Am 03.01.2022 um 18:24 schrieb Thomas Vandahl : > > Hi folks, > > We have fixed quite a few bugs and added some significant enhancements since > Apache Commons JCS 3.0 was released, so I would like to release Apache > Commons JCS 3.1. > > [X] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... My vote. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
