Re: [VOTE] Release Apache Commons IO 2.16.0 based on RC1
My +1 Gary On Mon, Mar 25, 2024, 9:51 AM Gary Gregory wrote: > We have fixed a few bugs and added some enhancements since Apache > Commons IO 2.15.1 was released, so I would like to release Apache > Commons IO 2.16.0. > > Apache Commons IO 2.16.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1 (svn > revision 68124) > > The Git tag commons-io-2.16.0-RC1 commit for this RC is > c0d44bcc782372980c9e6881537c801e6d84219f which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=c0d44bcc782372980c9e6881537c801e6d84219f > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-io.git > --branch commons-io-2.16.0-RC1 commons-io-2.16.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1708/commons-io/commons-io/2.16.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Mar 25 13:40:18 UTC 2024 > > commons-io-2.16.0-src.tar.gz=a97c6467f1ea48be8118c85f71360e775991b971b860b7371c3e184418bf14a3ac39a87379e427bab4aa8bd0283c1367882f06ae2f2fae423a0ed48b23335a70 > > commons-io-2.16.0-javadoc.jar=87d02e2bcc0d07b7bbf9d84fbade92b3964343c1d73fd931a78731a94edc18f3b2f0b5b726b8914d8d40c713f291b1d7b960079a34b240c183549c296120b48e > > commons-io-2.16.0-test-sources.jar=429106f6a17b81617107691307f3601fe160fd625b277e9983d27b5085e416b9570b6f41919d9d2a915ea0e1f788e43d46f88d9a0ff4468df12aa3b8dbbabc16 > > commons-io-2.16.0-bom.json=d29cad554cabb2cc68576bbff94956c0d096b70caca91e74729c749e615bbf40d49e398bb552676708f29a5b710e8d5a4797d72b9b3e1b5790bddba60bccb455 > > commons-io-2.16.0-bin.tar.gz=cae78a84809046989be88d8e2205597f14362c6deba5bd87744ed36d097b2395fdb3602ee2bd9017ea382e8772393565ac780eed15ca4c2b9c0e45b1fdb362cc > > commons-io-2.16.0-src.zip=a1e12a4b54ebe1c56359a962174a0d5457f91fcaef15827d84b03618ac876540e5f08551a5d11fe67e5d5c19c6ea5d987687ed5c74d372df08d95eb98e088dfa > > commons-io-2.16.0-bom.xml=75f6682f694432a76c3435c08a6f01c1dc6bec79026f1751c69af5957129ae876f82dfbf5464bfbaa084f9c0cdc5af671900230e76df6a4106d3e5d1ad5260c1 > > commons-io_commons-io-2.16.0.spdx.json=a76f8f587a6ee1d869ed789fd73ae13e3984462507a56807302eb8f4dc6ae406ae15b47e3f6c2f01de3252c6108a92c293a8d32f54be18aa77838314bbe878f6 > > commons-io-2.16.0-bin.zip=c40c47572f6716814a992c00291032a80a5ec6ac2910850f260450fea883288a7a582e583344a165235457eda4ef116c6e417e9eaeabfd7870e121a477416c62 > > commons-io-2.16.0-tests.jar=721cde073c07d2ae145309f9cebd568e1910d5a3809efeb7fc2cb04e789c4012fa45e36074e43d93b7795cf607acb8f3dfcf998aad996657e49c58618607f463 > > commons-io-2.16.0-sources.jar=6826bc3886a56e330fec6225d7e5550de640298e1bdd33739276819294e320334ffb81c9e04bea8c0b5138f2e135b6fee197b27f4347d59119c8728783b1841c > > I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P > jacoco -P japicmp clean package site deploy' using: > > openjdk version "17.0.10" 2024-01-16 > OpenJDK Runtime Environment Homebrew (build 17.0.10+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing) > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: /usr/local/Cellar/maven/3.9.6/libexec > Java version: 17.0.10, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac" > > Darwin 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58 > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64 > > Details of changes since 2.15.1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/index.html > (note some *relative* links are broken and the 2.16.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 2.15.1): > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 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, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > For following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag
[CANCEL][VOTE] Release Apache Commons Imaging 1.0.0-M1 based on RC1
Thank you for your thoughtful explanation. I'm 100% ok with calling the RC 1.0-alpha4 (alpha3 is was 2 years ago). I'll re-roll the RC in the morning. Gary On Tue, Mar 26, 2024, 6:07 PM Bruno Kinoshita wrote: > Hi Gary, > > The M name is something Maven uses a lot and (to me) suggests something > > users might be more willing to try than anything labeled alpha or beta. > > YMMV of course. > > > Now that you mention it, I do remember installing some Maven versions that > had the M in its version! > > From a compatibility POV, anything can happen until 1.0, so the only name > > that matters is 1.0. We have no guidelines except what the world does at > > large with alpha, beta, or milestone, plus I would not restrict > outlrselves > > saying we can't do this or that because we are in beta and not alpha > > anymore. The basic goal IMO is to up the usage and make sure we have a > nice > > API for 1.0. > > > I think users are already trying the -alpha release, and I think it'd be > better to use alpha3: > > - Less surprise to users, as alpha1 -> alpha2 -> alpha3 is intuitive > - Not all users may be familiar with M1, M2 (although that could be just > me) > - I searched milestone release maven, and found this SO as the very first > hit > > https://stackoverflow.com/questions/3687208/what-does-m1-mean-in-a-maven-repository > > >A milestone means that the application got a huge improvement from the > todo list. A release candidate is a release that can be the final release > unless some major bugs are found. > > I do not think we had a huge improvement, yet, as there are old issues from > the first 1.0 vote that were not fixed yet, and other bugs reported by > users of the alpha1/2 releases that would be nice to fix before it's ready > to be released. > > I think what we have in Imaging right now matches more the alpha release > described in ASF's release policy page > https://www.apache.org/legal/release-policy.html#release-types, > > > Releases that only represent a project milestone and are intended only > for bleeding-edge developers working outside the project are called > "alpha". > > as I think Imaging's API still needs some trimming and may change in > this/next releases, so more like a bleeding-edge, which should be clear to > users getting an alpha3 release. > > From my point of view we do not really need to increase the number of users > testing the releases, but work through the issues reported (mea culpa, > sorry), and fix the 1.x issues. Once that's done, I think we could have an > M1 release then, and promote it more to get more users before the 1.0 final > (if needed, or straight to 1.0). > > Wouldn't you consider an alpha3 instead, to avoid any issues to users, and > an M1 when we are closer to 1.0 (quite sure an alpha4 or M2 will be > needed... maybe more...). > > Bruno > > On Mon, 25 Mar 2024 at 16:24, Gary Gregory wrote: > > > Hi Bruno, > > > > The M name is something Maven uses a lot and (to me) suggests something > > users might be more willing to try than anything labeled alpha or beta. > > YMMV of course. > > > > From a compatibility POV, anything can happen until 1.0, so the only name > > that matters is 1.0. We have no guidelines except what the world does at > > large with alpha, beta, or milestone, plus I would not restrict > outlrselves > > saying we can't do this or that because we are in beta and not alpha > > anymore. The basic goal IMO is to up the usage and make sure we have a > nice > > API for 1.0. > > > > HTH, > > Gary > > > > > > On Mon, Mar 25, 2024, 10:49 AM Bruno Kinoshita > > wrote: > > > > > Will try the branch and vote later this week. > > > > > > From another thread, I think M1 will behave exatcly like an alpha > release > > > would. > > > > > > I am more used to alpha/beta/then final release process. > > > > > > Could you clarify how the M1 will distinguish from an alpha or 1.0 > > release? > > > > > > Tha ks for preparing the release! > > > > > > Bruno > > > > > > On Mon, 25 Mar 2024, 14:17 Gary Gregory, wrote: > > > > > > > We have fixed a few bugs and added some enhancements since Apache > > > > Commons Imaging 1.0-alpha3 was released, so I would like to release > > > > Apache Commons Imaging 1.0.0-M1. > > > > > > > > Apache Commons Imaging 1.0.0-M1 RC1 is available for review here: > > > > > > https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-M1-RC1 > > > > (svn revision 68122) > > > > > > > > The Git tag commons-imaging-1.0.0-M1-RC1 commit for this RC is > > > > 53565f604393f5f3e09b87be020567d201905a44 which you can browse here: > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=53565f604393f5f3e09b87be020567d201905a44 > > > > You may checkout this tag using: > > > > git clone > https://gitbox.apache.org/repos/asf/commons-imaging.git > > > > --branch < > > > https://gitbox.apache.org/repos/asf/commons-imaging.git--branch> > > > > commons-imaging-1.0.0-M1-RC1 commons-imaging-1.0.0-M1-RC1 > > > > >
Re: [LEGACY STAT] test suite from legacy includes non-free NIST data
This is something to ask Apache lawyers about. Yes, we're allowed to distribute this public US government data. No, that doesn't mean we can distribute it under the Apache license. Do we claim this is under the Apache license? I can't tell. The legal nitpicking is beyond me. On Tue, Mar 26, 2024 at 10:46 PM Orion Yeung wrote: > > Hello, > > I was unsure how to identify the component in the subject header here, but > I'd noticed you've got the standard reference NIST data in your repo, here: > > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data > > that we - on a statistics Rust crate - realized we needed to stop > redistributing in our repo. *I'm not a legal person, but I'm providing the > heads up as it may be a copyright violation. *Feel free to ask me for > clarifications. > > Some relevant links, > > [Fedora mailing list discussing this data when using the crate] ( > https://lists.fedoraproject.org/archives/list/legal%40lists.fedoraproject.org/thread/LSM6MO6TAHTIDNF5COCA6UWQDHWRF3AH/ > ) > [statrs GitHub issue mentioning this]( > https://github.com/statrs-dev/statrs/issues/195) > > Best, > -- > Orion Yeung > he / him -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LEGACY STAT] test suite from legacy includes non-free NIST data
Hi. Le mar. 26 mars 2024 à 23:46, Orion Yeung a écrit : > > Hello, > > I was unsure how to identify the component in the subject header here, but > I'd noticed you've got the standard reference NIST data in your repo, here: > > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data > > that we - on a statistics Rust crate - realized we needed to stop > redistributing in our repo. *I'm not a legal person, but I'm providing the > heads up as it may be a copyright violation. *Feel free to ask me for > clarifications. First result in a Google search: --- In general, publications of the National Institute of Standards and Technology, as publications of the Federal government, are in the public domain and not subject to copyright in the United States. Permission to reprint or copy from them is therefore not required. The original source should be credited. --- Also: https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications#data Doesn't this apply to the data being referred to? Excerpt: --- To the extent that NIST may hold copyright in countries other than the United States, you are hereby granted the non-exclusive irrevocable and unconditional right to print, publish, prepare derivative works and distribute the NIST data, in any medium, or authorize others to do so on your behalf, on a royalty-free basis throughout the world. ---CUT--- Regards, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LEGACY STAT] test suite from legacy includes non-free NIST data
Hello, I was unsure how to identify the component in the subject header here, but I'd noticed you've got the standard reference NIST data in your repo, here: https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data that we - on a statistics Rust crate - realized we needed to stop redistributing in our repo. *I'm not a legal person, but I'm providing the heads up as it may be a copyright violation. *Feel free to ask me for clarifications. Some relevant links, [Fedora mailing list discussing this data when using the crate] ( https://lists.fedoraproject.org/archives/list/legal%40lists.fedoraproject.org/thread/LSM6MO6TAHTIDNF5COCA6UWQDHWRF3AH/ ) [statrs GitHub issue mentioning this]( https://github.com/statrs-dev/statrs/issues/195) Best, -- Orion Yeung he / him
Re: [VOTE] Release Apache Commons Imaging 1.0.0-M1 based on RC1
Hi Gary, The M name is something Maven uses a lot and (to me) suggests something > users might be more willing to try than anything labeled alpha or beta. > YMMV of course. Now that you mention it, I do remember installing some Maven versions that had the M in its version! >From a compatibility POV, anything can happen until 1.0, so the only name > that matters is 1.0. We have no guidelines except what the world does at > large with alpha, beta, or milestone, plus I would not restrict outlrselves > saying we can't do this or that because we are in beta and not alpha > anymore. The basic goal IMO is to up the usage and make sure we have a nice > API for 1.0. I think users are already trying the -alpha release, and I think it'd be better to use alpha3: - Less surprise to users, as alpha1 -> alpha2 -> alpha3 is intuitive - Not all users may be familiar with M1, M2 (although that could be just me) - I searched milestone release maven, and found this SO as the very first hit https://stackoverflow.com/questions/3687208/what-does-m1-mean-in-a-maven-repository >A milestone means that the application got a huge improvement from the todo list. A release candidate is a release that can be the final release unless some major bugs are found. I do not think we had a huge improvement, yet, as there are old issues from the first 1.0 vote that were not fixed yet, and other bugs reported by users of the alpha1/2 releases that would be nice to fix before it's ready to be released. I think what we have in Imaging right now matches more the alpha release described in ASF's release policy page https://www.apache.org/legal/release-policy.html#release-types, > Releases that only represent a project milestone and are intended only for bleeding-edge developers working outside the project are called "alpha". as I think Imaging's API still needs some trimming and may change in this/next releases, so more like a bleeding-edge, which should be clear to users getting an alpha3 release. >From my point of view we do not really need to increase the number of users testing the releases, but work through the issues reported (mea culpa, sorry), and fix the 1.x issues. Once that's done, I think we could have an M1 release then, and promote it more to get more users before the 1.0 final (if needed, or straight to 1.0). Wouldn't you consider an alpha3 instead, to avoid any issues to users, and an M1 when we are closer to 1.0 (quite sure an alpha4 or M2 will be needed... maybe more...). Bruno On Mon, 25 Mar 2024 at 16:24, Gary Gregory wrote: > Hi Bruno, > > The M name is something Maven uses a lot and (to me) suggests something > users might be more willing to try than anything labeled alpha or beta. > YMMV of course. > > From a compatibility POV, anything can happen until 1.0, so the only name > that matters is 1.0. We have no guidelines except what the world does at > large with alpha, beta, or milestone, plus I would not restrict outlrselves > saying we can't do this or that because we are in beta and not alpha > anymore. The basic goal IMO is to up the usage and make sure we have a nice > API for 1.0. > > HTH, > Gary > > > On Mon, Mar 25, 2024, 10:49 AM Bruno Kinoshita > wrote: > > > Will try the branch and vote later this week. > > > > From another thread, I think M1 will behave exatcly like an alpha release > > would. > > > > I am more used to alpha/beta/then final release process. > > > > Could you clarify how the M1 will distinguish from an alpha or 1.0 > release? > > > > Tha ks for preparing the release! > > > > Bruno > > > > On Mon, 25 Mar 2024, 14:17 Gary Gregory, wrote: > > > > > We have fixed a few bugs and added some enhancements since Apache > > > Commons Imaging 1.0-alpha3 was released, so I would like to release > > > Apache Commons Imaging 1.0.0-M1. > > > > > > Apache Commons Imaging 1.0.0-M1 RC1 is available for review here: > > > > https://dist.apache.org/repos/dist/dev/commons/imaging/1.0.0-M1-RC1 > > > (svn revision 68122) > > > > > > The Git tag commons-imaging-1.0.0-M1-RC1 commit for this RC is > > > 53565f604393f5f3e09b87be020567d201905a44 which you can browse here: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=commons-imaging.git;a=commit;h=53565f604393f5f3e09b87be020567d201905a44 > > > You may checkout this tag using: > > > git clone https://gitbox.apache.org/repos/asf/commons-imaging.git > > > --branch < > > https://gitbox.apache.org/repos/asf/commons-imaging.git--branch> > > > commons-imaging-1.0.0-M1-RC1 commons-imaging-1.0.0-M1-RC1 > > > > > > Maven artifacts are here: > > > > > > > > > https://repository.apache.org/content/repositories/orgapachecommons-1707/org/apache/commons/commons-imaging/1.0.0-M1/ > > > > > > These are the artifacts and their hashes: > > > > > > #Release SHA-512s > > > #Mon Mar 25 12:37:27 UTC 2024 > > > > > > > > > org.apache.commons_commons-imaging-1.0.0-M1.spdx.json=87c9326b12ddb92d53483141f825fad966c432405120f1296f70a6dba54f7ca87f80af26ce209bcca8bdd89b4e93a
Re: [VOTE] Release Apache Commons IO 2.16.0 based on RC1
+1 Build passing from tag on Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) Maven home: /opt/apache-maven-3.8.5 Java version: 17.0.10, vendor: Private Build, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-101-generic", arch: "amd64", family: "unix" Site reports look good, checked dist area files and found no issues. Thanks! On Mon, 25 Mar 2024 at 14:51, Gary Gregory wrote: > We have fixed a few bugs and added some enhancements since Apache > Commons IO 2.15.1 was released, so I would like to release Apache > Commons IO 2.16.0. > > Apache Commons IO 2.16.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1 (svn > revision 68124) > > The Git tag commons-io-2.16.0-RC1 commit for this RC is > c0d44bcc782372980c9e6881537c801e6d84219f which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=c0d44bcc782372980c9e6881537c801e6d84219f > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-io.git > --branch commons-io-2.16.0-RC1 commons-io-2.16.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1708/commons-io/commons-io/2.16.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Mar 25 13:40:18 UTC 2024 > > commons-io-2.16.0-src.tar.gz=a97c6467f1ea48be8118c85f71360e775991b971b860b7371c3e184418bf14a3ac39a87379e427bab4aa8bd0283c1367882f06ae2f2fae423a0ed48b23335a70 > > commons-io-2.16.0-javadoc.jar=87d02e2bcc0d07b7bbf9d84fbade92b3964343c1d73fd931a78731a94edc18f3b2f0b5b726b8914d8d40c713f291b1d7b960079a34b240c183549c296120b48e > > commons-io-2.16.0-test-sources.jar=429106f6a17b81617107691307f3601fe160fd625b277e9983d27b5085e416b9570b6f41919d9d2a915ea0e1f788e43d46f88d9a0ff4468df12aa3b8dbbabc16 > > commons-io-2.16.0-bom.json=d29cad554cabb2cc68576bbff94956c0d096b70caca91e74729c749e615bbf40d49e398bb552676708f29a5b710e8d5a4797d72b9b3e1b5790bddba60bccb455 > > commons-io-2.16.0-bin.tar.gz=cae78a84809046989be88d8e2205597f14362c6deba5bd87744ed36d097b2395fdb3602ee2bd9017ea382e8772393565ac780eed15ca4c2b9c0e45b1fdb362cc > > commons-io-2.16.0-src.zip=a1e12a4b54ebe1c56359a962174a0d5457f91fcaef15827d84b03618ac876540e5f08551a5d11fe67e5d5c19c6ea5d987687ed5c74d372df08d95eb98e088dfa > > commons-io-2.16.0-bom.xml=75f6682f694432a76c3435c08a6f01c1dc6bec79026f1751c69af5957129ae876f82dfbf5464bfbaa084f9c0cdc5af671900230e76df6a4106d3e5d1ad5260c1 > > commons-io_commons-io-2.16.0.spdx.json=a76f8f587a6ee1d869ed789fd73ae13e3984462507a56807302eb8f4dc6ae406ae15b47e3f6c2f01de3252c6108a92c293a8d32f54be18aa77838314bbe878f6 > > commons-io-2.16.0-bin.zip=c40c47572f6716814a992c00291032a80a5ec6ac2910850f260450fea883288a7a582e583344a165235457eda4ef116c6e417e9eaeabfd7870e121a477416c62 > > commons-io-2.16.0-tests.jar=721cde073c07d2ae145309f9cebd568e1910d5a3809efeb7fc2cb04e789c4012fa45e36074e43d93b7795cf607acb8f3dfcf998aad996657e49c58618607f463 > > commons-io-2.16.0-sources.jar=6826bc3886a56e330fec6225d7e5550de640298e1bdd33739276819294e320334ffb81c9e04bea8c0b5138f2e135b6fee197b27f4347d59119c8728783b1841c > > I have tested this with 'mvn' and 'mvn -V -Prelease -Ptest-deploy -P > jacoco -P japicmp clean package site deploy' using: > > openjdk version "17.0.10" 2024-01-16 > OpenJDK Runtime Environment Homebrew (build 17.0.10+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.10+0, mixed mode, sharing) > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) > Maven home: /usr/local/Cellar/maven/3.9.6/libexec > Java version: 17.0.10, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.10/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.3.1", arch: "x86_64", family: "mac" > > Darwin 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:28:58 > PST 2023; root:xnu-10002.81.5~7/RELEASE_X86_64 x86_64 > > Details of changes since 2.15.1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/index.html > (note some *relative* links are broken and the 2.16.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 2.15.1): > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/io/2.16.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because.
