Re: [pool] 2.12.0 update
Thanks for the update, no need to apologize :-) Gary On Sat, Sep 9, 2023, 6:31 PM Phil Steitz wrote: > Sorry I got busy. I will they to get final changes in tomorrow or > convince myself it is ok to release without them. Apologies for the delay > > > On Sep 9, 2023, at 6:41 AM, Gary Gregory wrote: > > > > Hi Phil, > > > > Where are we on a 2.12.0 release candidate? > > > > Gary > > > >> On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz > wrote: > >> > >> OK, I found the source of the performance hit. In the POOL-411 > changes, we > >> had inadvertently forced every register to acquire a write lock from the > >> keylock. I think I also finally definitively fixed the root issue > there. > >> The tricky bit about the numInterested tracking is that the counters are > >> attached to the ObjectDeques, which can be replaced. If this happens > while > >> waiting for a write lock in either register or deregister, the code can > end > >> up updating the counter on a pool that has been replaced. I added > checks > >> to trap deregistration of a null pool (should never happen) and followed > >> Sebb's suggestion to add a check for numInterested going negative. The > >> accounting setup is very efficient, but tricky to maintain. For 3.0, we > >> might consider moving numInterested tracking to a hashmap. For 2.x, I > >> think the setup is fixed now and performance is the same as earlier > >> versions. Soak tests look good. > >> > >> One last thing I would like to do before we cut 2.12.0: > >> > >> We are going to be making incompatible changes in 3.0 and I don't think > we > >> need to telegraph all of the API changes via deprecations in 2.x - most > >> notably the recent method name changes of the form s/Time/Duration. I > >> understand the rationale for these changes, but they make the 2.x code > very > >> messy with double deprecations - first from the "millis" methods and > then > >> from "Time" to "Duration." I think it would be better to keep the > existing > >> deprecations for the "millis" methods, but drop the new "Duration" ones > and > >> remove deprecations for the ones they replace. I can see the argument > that > >> it is better to tell users now, but that takes away flexibility in 3.0 > and > >> makes the API look very confusing with so many methods that do the same > >> thing. Any objections ? > >> > >> Phil > >> > >>> On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz > wrote: > >>> > >>> I have run my first round of soak and performance tests on what is now > in > >>> the 2.x branch. Good news is the code looks stable. Not so good news > is > >>> it appears that GKOP performance has taken a material hit vs 2.11 and > >>> earlier versions. I need to confirm this via more targeted tests and > if it > >>> turns out not to be real, figure out what is causing it. Hopefully I > will > >>> get to this done in the next few days. > >>> > >>> Phil > >>> > > > > - > > 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: [pool] 2.12.0 update
Sorry I got busy. I will they to get final changes in tomorrow or convince myself it is ok to release without them. Apologies for the delay > On Sep 9, 2023, at 6:41 AM, Gary Gregory wrote: > > Hi Phil, > > Where are we on a 2.12.0 release candidate? > > Gary > >> On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz wrote: >> >> OK, I found the source of the performance hit. In the POOL-411 changes, we >> had inadvertently forced every register to acquire a write lock from the >> keylock. I think I also finally definitively fixed the root issue there. >> The tricky bit about the numInterested tracking is that the counters are >> attached to the ObjectDeques, which can be replaced. If this happens while >> waiting for a write lock in either register or deregister, the code can end >> up updating the counter on a pool that has been replaced. I added checks >> to trap deregistration of a null pool (should never happen) and followed >> Sebb's suggestion to add a check for numInterested going negative. The >> accounting setup is very efficient, but tricky to maintain. For 3.0, we >> might consider moving numInterested tracking to a hashmap. For 2.x, I >> think the setup is fixed now and performance is the same as earlier >> versions. Soak tests look good. >> >> One last thing I would like to do before we cut 2.12.0: >> >> We are going to be making incompatible changes in 3.0 and I don't think we >> need to telegraph all of the API changes via deprecations in 2.x - most >> notably the recent method name changes of the form s/Time/Duration. I >> understand the rationale for these changes, but they make the 2.x code very >> messy with double deprecations - first from the "millis" methods and then >> from "Time" to "Duration." I think it would be better to keep the existing >> deprecations for the "millis" methods, but drop the new "Duration" ones and >> remove deprecations for the ones they replace. I can see the argument that >> it is better to tell users now, but that takes away flexibility in 3.0 and >> makes the API look very confusing with so many methods that do the same >> thing. Any objections ? >> >> Phil >> >>> On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz wrote: >>> >>> I have run my first round of soak and performance tests on what is now in >>> the 2.x branch. Good news is the code looks stable. Not so good news is >>> it appears that GKOP performance has taken a material hit vs 2.11 and >>> earlier versions. I need to confirm this via more targeted tests and if it >>> turns out not to be real, figure out what is causing it. Hopefully I will >>> get to this done in the next few days. >>> >>> Phil >>> > > - > 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
[CRYPTO] test failures with JNA
Some of the test runs fail when testing with the class: org.apache.commons.crypto.jna.OpenSslJna It looks like all the OSes complete the test OK if the default JNA library is used. However for some reason its version does not always agree with the default openSSL version. This library can be overridden by suitable use of the jna.library.path property. This is not necessary for Ubuntu, as it defaults to the correct library version. For macos one can use the lib from the ENGINESDIR value shown by 'openssl version -a'. I've not yet been able to find how to override the windows library successfully. Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons DbUtils 1.8.1 based on RC1
Builds on java 8,11, 17 signatures good Rat good all other reports good. +1 > On Sep 9, 2023, at 8:46 AM, Gary Gregory wrote: > > We have fixed one (Java JPMS >= 9) bug since Apache Commons DbUtils > 1.8.0 was released, so I would like to release Apache Commons DbUtils > 1.8.1. > > Apache Commons DbUtils 1.8.1 RC1 is available for review here: >https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1 > (svn revision 63886) > > The Git tag commons-dbutils-1.8.1-RC1 commit for this RC is > 0b30ed1bddfa07bfda44122fc52ccd0e49fb6006 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-dbutils.git;a=commit;h=0b30ed1bddfa07bfda44122fc52ccd0e49fb6006 > You may checkout this tag using: >git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git > --branch commons-dbutils-1.8.1-RC1 commons-dbutils-1.8.1-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1655/commons-dbutils/commons-dbutils/1.8.1/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sat Sep 09 08:40:12 EDT 2023 > commons-dbutils-1.8.1-src.tar.gz=dca3c72a7601d8d97886513c13f7bfb132711b05ecff7c9e17d9e9169da55dc24d87d8d491e08cf210b9580fd73db0213f307ce08a09136d279f4cc39d3f303e > commons-dbutils-1.8.1-test-sources.jar=c52dd3a7c5fa1757c04244b780f4ce6882ea9d2592956a2902f6e88e5af824fb70e5d0e3cc42e89e4597641beda4b9c8fa558abe3644ddab146d5bd997a2618e > commons-dbutils-1.8.1-javadoc.jar=1a6ff00095bff09fdba43c50e5a8ae70feaf0a7dc1b8e9a6194596b775b2cd10c55504dfcb330a2004db692efe685bc462caec7372d27df23608ce71fe477d78 > commons-dbutils-1.8.1-tests.jar=dabaac62f735cbc9c4ae4d72bd7ffcc435a5f9e01baf4cbf2b4f639d0fcbd3892fceb8e0974605bb8d700ae764c77c16fb198f10cedd405b05169a2957066083 > commons-dbutils-1.8.1-src.zip=ff5eea293a6c8db1350d2ac24cad68c77f8bfcc2e2f5ddabd42a46167bb8f9e7d2917f8449207bb049fe2035324531029ec5ed9895b9587b3a1da1039bd6 > commons-dbutils-1.8.1-bom.json=d23f12585120e122476a70e3163c8034b87e8a2e3e3bfbb8294bc9d5a0f7512c394cc30c07053cb86a1bc6844d4548fb6d967898bc58c6e86eb73018726c8bc1 > commons-dbutils-1.8.1-bin.tar.gz=458dbca14ef7dbb034dcc01ed806bb4fa6fbf772b3bec7edfb1c530c0239cac9662a9733208ab68e4d3e436efd06bf9b97344595476c855637db2fae22992813 > commons-dbutils-1.8.1-bin.zip=91a6bb68ae6601759b01848430ae0a9e1b8343980eeef5e2cf94e51c91aedbd90a4efd3aa898525fe6cec97ec10d8b315d1be32be51e11ea897d83a14458a2d7 > commons-dbutils_commons-dbutils-1.8.1.spdx.json=c03b89c24e6e34a23b78fd651714292ef6efd6ad76a483aaeeae66aa362e9dcf5f1d22bc4f36b4c5acf09a6fe0ebd9fa6deceac28baba8aaa4a407daff50d0c4 > commons-dbutils-1.8.1-sources.jar=6b383531b6b4dd71b5871d39eaa975bb28e65b0f4d0def0e7ffdea4a6b0b7420381145a8ae29206ab56353c1014ab48f94051038224dcf9750e51c4a630e2fab > commons-dbutils-1.8.1-bom.xml=f3d472aeadf54d85d42271c1d7ade15a5b4bcc4acfa3b3facecbf2d42f002105ff8d2eac73121d52e3e97f603082162676f7a9a258b46baa8749c4283b680cb7 > > > I have tested this with 'mvn' using: > > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) > Maven home: /usr/local/Cellar/maven/3.9.4/libexec > Java version: 17.0.8.1, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac" > Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:21:56 > PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64 > > Details of changes since 1.8.0 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/index.html >(note some *relative* links are broken and the 1.8.1 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.8.0): > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-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 > > git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git
Re: [pool] 2.12.0 update
Hi Phil, Where are we on a 2.12.0 release candidate? Gary On Mon, Jul 31, 2023 at 10:33 PM Phil Steitz wrote: > > OK, I found the source of the performance hit. In the POOL-411 changes, we > had inadvertently forced every register to acquire a write lock from the > keylock. I think I also finally definitively fixed the root issue there. > The tricky bit about the numInterested tracking is that the counters are > attached to the ObjectDeques, which can be replaced. If this happens while > waiting for a write lock in either register or deregister, the code can end > up updating the counter on a pool that has been replaced. I added checks > to trap deregistration of a null pool (should never happen) and followed > Sebb's suggestion to add a check for numInterested going negative. The > accounting setup is very efficient, but tricky to maintain. For 3.0, we > might consider moving numInterested tracking to a hashmap. For 2.x, I > think the setup is fixed now and performance is the same as earlier > versions. Soak tests look good. > > One last thing I would like to do before we cut 2.12.0: > > We are going to be making incompatible changes in 3.0 and I don't think we > need to telegraph all of the API changes via deprecations in 2.x - most > notably the recent method name changes of the form s/Time/Duration. I > understand the rationale for these changes, but they make the 2.x code very > messy with double deprecations - first from the "millis" methods and then > from "Time" to "Duration." I think it would be better to keep the existing > deprecations for the "millis" methods, but drop the new "Duration" ones and > remove deprecations for the ones they replace. I can see the argument that > it is better to tell users now, but that takes away flexibility in 3.0 and > makes the API look very confusing with so many methods that do the same > thing. Any objections ? > > Phil > > On Sat, Jul 29, 2023 at 3:59 PM Phil Steitz wrote: > > > I have run my first round of soak and performance tests on what is now in > > the 2.x branch. Good news is the code looks stable. Not so good news is > > it appears that GKOP performance has taken a material hit vs 2.11 and > > earlier versions. I need to confirm this via more targeted tests and if it > > turns out not to be real, figure out what is causing it. Hopefully I will > > get to this done in the next few days. > > > > Phil > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons DbUtils 1.8.1 based on RC1
Vote [ +1 ] Site builds correctly (jdk8), reports are ok. Tidbits: some Checkstyle and Javadoc (jdk17) errors could be addressed Check build using: mvn -s "$HOME/.m2/commons-settings.xml" With: Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Maven home: /Users/hbiestro/Java/apache-maven-3.9.4 Java version: 1.8.0_352, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.5.1", arch: "aarch64", family: "mac" Darwin hbiestro-MBP16 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64 and Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Maven home: /Users/hbiestro/Java/apache-maven-3.9.4 Java version: 17.0.8, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.5.1", arch: "aarch64", family: "mac" Darwin hbiestro-MBP16 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 arm64 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Apache Commons DbUtils 1.8.1 based on RC1
We have fixed one (Java JPMS >= 9) bug since Apache Commons DbUtils 1.8.0 was released, so I would like to release Apache Commons DbUtils 1.8.1. Apache Commons DbUtils 1.8.1 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1 (svn revision 63886) The Git tag commons-dbutils-1.8.1-RC1 commit for this RC is 0b30ed1bddfa07bfda44122fc52ccd0e49fb6006 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-dbutils.git;a=commit;h=0b30ed1bddfa07bfda44122fc52ccd0e49fb6006 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git --branch commons-dbutils-1.8.1-RC1 commons-dbutils-1.8.1-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1655/commons-dbutils/commons-dbutils/1.8.1/ These are the artifacts and their hashes: #Release SHA-512s #Sat Sep 09 08:40:12 EDT 2023 commons-dbutils-1.8.1-src.tar.gz=dca3c72a7601d8d97886513c13f7bfb132711b05ecff7c9e17d9e9169da55dc24d87d8d491e08cf210b9580fd73db0213f307ce08a09136d279f4cc39d3f303e commons-dbutils-1.8.1-test-sources.jar=c52dd3a7c5fa1757c04244b780f4ce6882ea9d2592956a2902f6e88e5af824fb70e5d0e3cc42e89e4597641beda4b9c8fa558abe3644ddab146d5bd997a2618e commons-dbutils-1.8.1-javadoc.jar=1a6ff00095bff09fdba43c50e5a8ae70feaf0a7dc1b8e9a6194596b775b2cd10c55504dfcb330a2004db692efe685bc462caec7372d27df23608ce71fe477d78 commons-dbutils-1.8.1-tests.jar=dabaac62f735cbc9c4ae4d72bd7ffcc435a5f9e01baf4cbf2b4f639d0fcbd3892fceb8e0974605bb8d700ae764c77c16fb198f10cedd405b05169a2957066083 commons-dbutils-1.8.1-src.zip=ff5eea293a6c8db1350d2ac24cad68c77f8bfcc2e2f5ddabd42a46167bb8f9e7d2917f8449207bb049fe2035324531029ec5ed9895b9587b3a1da1039bd6 commons-dbutils-1.8.1-bom.json=d23f12585120e122476a70e3163c8034b87e8a2e3e3bfbb8294bc9d5a0f7512c394cc30c07053cb86a1bc6844d4548fb6d967898bc58c6e86eb73018726c8bc1 commons-dbutils-1.8.1-bin.tar.gz=458dbca14ef7dbb034dcc01ed806bb4fa6fbf772b3bec7edfb1c530c0239cac9662a9733208ab68e4d3e436efd06bf9b97344595476c855637db2fae22992813 commons-dbutils-1.8.1-bin.zip=91a6bb68ae6601759b01848430ae0a9e1b8343980eeef5e2cf94e51c91aedbd90a4efd3aa898525fe6cec97ec10d8b315d1be32be51e11ea897d83a14458a2d7 commons-dbutils_commons-dbutils-1.8.1.spdx.json=c03b89c24e6e34a23b78fd651714292ef6efd6ad76a483aaeeae66aa362e9dcf5f1d22bc4f36b4c5acf09a6fe0ebd9fa6deceac28baba8aaa4a407daff50d0c4 commons-dbutils-1.8.1-sources.jar=6b383531b6b4dd71b5871d39eaa975bb28e65b0f4d0def0e7ffdea4a6b0b7420381145a8ae29206ab56353c1014ab48f94051038224dcf9750e51c4a630e2fab commons-dbutils-1.8.1-bom.xml=f3d472aeadf54d85d42271c1d7ade15a5b4bcc4acfa3b3facecbf2d42f002105ff8d2eac73121d52e3e97f603082162676f7a9a258b46baa8749c4283b680cb7 I have tested this with 'mvn' using: Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9) Maven home: /usr/local/Cellar/maven/3.9.4/libexec Java version: 17.0.8.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "13.5.1", arch: "x86_64", family: "mac" Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul 5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 x86_64 Details of changes since 1.8.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/index.html (note some *relative* links are broken and the 1.8.1 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 1.8.0): https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-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 git clone https://gitbox.apache.org/repos/asf/commons-dbutils.git --branch commons-dbutils-1.8.1-RC1 commons-dbutils-1.8.1-RC1 cd commons-dbutils-1.8.1-RC1 1b) Download and unpack the source archive from: https://dist.apache.org/repos/dist/dev/commons/dbutils/1.8.1-RC1/source 2) Check Apache licenses This step is not required if the site includes a RAT report page which
Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
+1 LGTM On Sat, Sep 9, 2023 at 11:57 AM Gary Gregory wrote: > > Maven coordinates changed because the package name changed per our > conventions. > > Gary > > On Sat, Sep 9, 2023, 7:53 AM Elliotte Rusty Harold > wrote: > > > To be clear, not just the Maven coordinates but also the package names > > have changed (to fileupload2) in this release? If so, this should be > > fine. I just want to double check because this step is often missed, > > with real much client pain resulting. > > > > On Fri, Sep 8, 2023 at 10:19 PM sebb wrote: > > > > > > FTR: > > > > > > Note that this release uses different Maven coordinates: > > > > > > org.apache.commons > > > commons-fileupload2 > > > 2.0.0-M2-SNAPSHOT > > > > > > The previous release (1.5) used: > > > > > > commons-fileupload > > > commons-fileupload > > > 1.5 > > > > > > On Fri, 21 Jul 2023 at 17:28, > > wrote: > > > > > > > > Hello Gary, > > > > > > > > does that include Milestone releases as well or not? > > > > > > > > Regards > > > > Jeremias > > > > > > > > -Original Message- > > > > From: Gary Gregory > > > > Sent: Friday, 21 July 2023 17:08 > > > > To: Commons Developers List > > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > > > [**EXTERNAL E-MAIL**] > > > > > > > > All releases go to MC. > > > > > > > > Gary > > > > > > > > On Fri, Jul 21, 2023, 10:47 > > > > > > wrote: > > > > > > > > > Hello Gary, > > > > > > > > > > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven > > > > > Central as well? > > > > > That would make the testing easier. > > > > > > > > > > Regards > > > > > Jeremias > > > > > > > > > > -Original Message- > > > > > From: Gary Gregory > > > > > Sent: Friday, 21 July 2023 15:43 > > > > > To: Commons Developers List > > > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > > > > > [**EXTERNAL E-MAIL**] > > > > > > > > > > This is a milestone release because we might not have the gotten the > > > > > API just right for a major release. This gives up the opportunity to > > > > > receive feedback and adjust the API for what will be 2.0.0. All lot > > of > > > > > folks will not try a snapshot build, which then leaves us in the > > dark. > > > > > > > > > > WRT to the missing data, I'll adjust that but it won't show up on the > > > > > site until the next version is published. > > > > > > > > > > HTH, > > > > > Gary > > > > > > > > > > > > > > > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger > > > > > wrote: > > > > > > > > > > > Hi Gary! > > > > > > > > > > > > Thank you for this release and thanks to all the diligent > > contributors! > > > > > > Having a new release with new features, cleaned-up interfaces, and > > > > > > updated dependencies is much appreciated! > > > > > > I also learned from the recent discussion whether FileUpload is > > > > > > still a good idea [1]. > > > > > > > > > > > > > The Apache Commons FileUpload Parent team is pleased to announce > > > > > > the > release of Apache Commons FileUpload Parent 2.0.0-M1. > > > > > > > > > > > > Why is the release called "-M1" and not plain 2.0.0? > > > > > > > > > > > > When I follow > > > > > > https://commons.apache.org/proper/commons-fileupload/ > > > > > > the top release entry in the Downloading section for version 2.0.0 > > > > > > lacks the release date. > > > > > > > > > > > > Kind regards, > > > > > > Christoph > > > > > > > > > > > > > > > > > > [1] > > https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9 > > > > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > > > > have received this e-mail by mistake, and delete it. We thank you for > > > > > your support. > > > > > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > have received this e-mail by mistake, and delete it. We thank you for your > > support. > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > -- > > 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 > > > > -- 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
[ANNOUNCEMENT] Apache Commons Compress 1.24.0
The Apache Commons Team announces Apache Commons Compress 1.24.0. Apache Commons Compress defines an API for working with compression and archive formats. These include: bzip2, gzip, pack200, lzma, xz, Snappy, traditional Unix Compress, DEFLATE, DEFLATE64, LZ4, Brotli, Zstandard and ar, cpio, jar, tar, zip, dump, 7z, arj. New features, fixed bugs, and changes: https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0 For complete information on Apache Commons Compress, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Compress website: https://commons.apache.org/compress/ Download it from https://commons.apache.org/compress/download_compress.cgi Gary Gregory, Apache Commons - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
Maven coordinates changed because the package name changed per our conventions. Gary On Sat, Sep 9, 2023, 7:53 AM Elliotte Rusty Harold wrote: > To be clear, not just the Maven coordinates but also the package names > have changed (to fileupload2) in this release? If so, this should be > fine. I just want to double check because this step is often missed, > with real much client pain resulting. > > On Fri, Sep 8, 2023 at 10:19 PM sebb wrote: > > > > FTR: > > > > Note that this release uses different Maven coordinates: > > > > org.apache.commons > > commons-fileupload2 > > 2.0.0-M2-SNAPSHOT > > > > The previous release (1.5) used: > > > > commons-fileupload > > commons-fileupload > > 1.5 > > > > On Fri, 21 Jul 2023 at 17:28, > wrote: > > > > > > Hello Gary, > > > > > > does that include Milestone releases as well or not? > > > > > > Regards > > > Jeremias > > > > > > -Original Message- > > > From: Gary Gregory > > > Sent: Friday, 21 July 2023 17:08 > > > To: Commons Developers List > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > [**EXTERNAL E-MAIL**] > > > > > > All releases go to MC. > > > > > > Gary > > > > > > On Fri, Jul 21, 2023, 10:47 > > > > wrote: > > > > > > > Hello Gary, > > > > > > > > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven > > > > Central as well? > > > > That would make the testing easier. > > > > > > > > Regards > > > > Jeremias > > > > > > > > -Original Message- > > > > From: Gary Gregory > > > > Sent: Friday, 21 July 2023 15:43 > > > > To: Commons Developers List > > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > > > [**EXTERNAL E-MAIL**] > > > > > > > > This is a milestone release because we might not have the gotten the > > > > API just right for a major release. This gives up the opportunity to > > > > receive feedback and adjust the API for what will be 2.0.0. All lot > of > > > > folks will not try a snapshot build, which then leaves us in the > dark. > > > > > > > > WRT to the missing data, I'll adjust that but it won't show up on the > > > > site until the next version is published. > > > > > > > > HTH, > > > > Gary > > > > > > > > > > > > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger > > > > wrote: > > > > > > > > > Hi Gary! > > > > > > > > > > Thank you for this release and thanks to all the diligent > contributors! > > > > > Having a new release with new features, cleaned-up interfaces, and > > > > > updated dependencies is much appreciated! > > > > > I also learned from the recent discussion whether FileUpload is > > > > > still a good idea [1]. > > > > > > > > > > > The Apache Commons FileUpload Parent team is pleased to announce > > > > > the > release of Apache Commons FileUpload Parent 2.0.0-M1. > > > > > > > > > > Why is the release called "-M1" and not plain 2.0.0? > > > > > > > > > > When I follow > > > > > https://commons.apache.org/proper/commons-fileupload/ > > > > > the top release entry in the Downloading section for version 2.0.0 > > > > > lacks the release date. > > > > > > > > > > Kind regards, > > > > > Christoph > > > > > > > > > > > > > > > [1] > https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9 > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > > > have received this e-mail by mistake, and delete it. We thank you for > > > > your support. > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > have received this e-mail by mistake, and delete it. We thank you for your > support. > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- > 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: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1
To be clear, not just the Maven coordinates but also the package names have changed (to fileupload2) in this release? If so, this should be fine. I just want to double check because this step is often missed, with real much client pain resulting. On Fri, Sep 8, 2023 at 10:19 PM sebb wrote: > > FTR: > > Note that this release uses different Maven coordinates: > > org.apache.commons > commons-fileupload2 > 2.0.0-M2-SNAPSHOT > > The previous release (1.5) used: > > commons-fileupload > commons-fileupload > 1.5 > > On Fri, 21 Jul 2023 at 17:28, > wrote: > > > > Hello Gary, > > > > does that include Milestone releases as well or not? > > > > Regards > > Jeremias > > > > -Original Message- > > From: Gary Gregory > > Sent: Friday, 21 July 2023 17:08 > > To: Commons Developers List > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > [**EXTERNAL E-MAIL**] > > > > All releases go to MC. > > > > Gary > > > > On Fri, Jul 21, 2023, 10:47 > > wrote: > > > > > Hello Gary, > > > > > > are you releasing the Apache Commons FileUpload 2.0.0-M1 to Maven > > > Central as well? > > > That would make the testing easier. > > > > > > Regards > > > Jeremias > > > > > > -Original Message- > > > From: Gary Gregory > > > Sent: Friday, 21 July 2023 15:43 > > > To: Commons Developers List > > > Subject: Re: [ANNOUNCE] Apache Commons FileUpload 2.0.0-M1 > > > > > > [**EXTERNAL E-MAIL**] > > > > > > This is a milestone release because we might not have the gotten the > > > API just right for a major release. This gives up the opportunity to > > > receive feedback and adjust the API for what will be 2.0.0. All lot of > > > folks will not try a snapshot build, which then leaves us in the dark. > > > > > > WRT to the missing data, I'll adjust that but it won't show up on the > > > site until the next version is published. > > > > > > HTH, > > > Gary > > > > > > > > > On Fri, Jul 21, 2023, 08:53 Christoph Grüninger > > > wrote: > > > > > > > Hi Gary! > > > > > > > > Thank you for this release and thanks to all the diligent contributors! > > > > Having a new release with new features, cleaned-up interfaces, and > > > > updated dependencies is much appreciated! > > > > I also learned from the recent discussion whether FileUpload is > > > > still a good idea [1]. > > > > > > > > > The Apache Commons FileUpload Parent team is pleased to announce > > > > the > release of Apache Commons FileUpload Parent 2.0.0-M1. > > > > > > > > Why is the release called "-M1" and not plain 2.0.0? > > > > > > > > When I follow > > > > https://commons.apache.org/proper/commons-fileupload/ > > > > the top release entry in the Downloading section for version 2.0.0 > > > > lacks the release date. > > > > > > > > Kind regards, > > > > Christoph > > > > > > > > > > > > [1] https://lists.apache.org/thread/js8fccsvwbgx9x6ntpy0v0br1cbb77n9 > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > If you are not the addressee, please inform us immediately that you > > > have received this e-mail by mistake, and delete it. We thank you for > > > your support. > > > > > > > > > > If you are not the addressee, please inform us immediately that you have > > received this e-mail by mistake, and delete it. We thank you for your > > support. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- 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
