Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
[X] +1 Release these artifacts Build from tag passed with `mvn clean install site` on Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T06:33:14+12:00) Maven home: /opt/apache-maven-3.5.4 Java version: 1.8.0_232, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre Default locale: en_NZ, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-72-generic", arch: "amd64", family: "unix" Build with same command as above passed fine too with JDK 13, using the ZIP sources from the dist area. Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T06:33:14+12:00) Maven home: /opt/apache-maven-3.5.4 Java version: 13, vendor: Oracle Corporation, runtime: /home/kinow/Development/java/jdk-13 Default locale: en_NZ, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-72-generic", arch: "amd64", family: "unix" Had a look at files in the dist area and fond no issues. Site reports look good. Checked signatures and found no issues too. ThanksBruno On Tuesday, 31 December 2019, 2:00:12 pm NZDT, Gary Gregory wrote: We have fixed quite a few bugs and added some significant enhancements since Apache Commons Codec 1.13 was released, so I would like to release Apache Commons Codec 1.14. Apache Commons Codec 1.14 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn revision 37409) The Git tag commons-codec-1.14-RC1 commit for this RC is af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ These are the artifacts and their hashes: #Release SHA-512s #Mon Dec 30 19:44:19 EST 2019 commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 I have tested this with: mvn -V -Duser.name=%my_apache_id% -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy using: Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: C:\Java\apache-maven-3.6.3\bin\.. Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_231\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Details of changes since 1.13 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html (note some *relative* links are broken and the 1.14 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 1.13): https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html RAT Report: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) For following is intended as a helper and refresher for reviewers. Validating a release candidate
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
Sorry, missed this one. On it. Vote e-mail should be in within the next 30 mins. Bruno On Friday, 3 January 2020, 10:58:23 am NZDT, Gary Gregory wrote: May we get more PMC reviews please? Gary On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Codec 1.13 was released, so I would like to release > Apache Commons Codec 1.14. > > Apache Commons Codec 1.14 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn > revision 37409) > > The Git tag commons-codec-1.14-RC1 commit for this RC is > af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-codec.git > --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Dec 30 19:44:19 EST 2019 > > commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf > > commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 > > commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a > > commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 > > commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b > > commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e > > commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 > > commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 > > I have tested this with: > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease > -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_231\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.13 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html > (note some *relative* links are broken and the 1.14 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.13): > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, > > 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. > > 1) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch > commons-codec-1.14-RC1 commons-codec-1.14-RC1 > cd commons-codec-1.14-RC1 > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which you > then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page which > you then must check. > > mvn
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
> On Jan 2, 2020, at 6:55 PM, Alex Herbert wrote: > > > >> On 2 Jan 2020, at 16:53, Rob Tompkins wrote: >> >> +0 (could be convinced of +1) >> >> RAT: >> >> * >> Summary >> --- >> Generated at: 2020-01-02T10:45:36-05:00 >> >> Notes: 3 >> Binaries: 4 >> Archives: 1 >> Standards: 287 >> >> Apache Licensed: 286 >> Generated Documents: 0 >> >> JavaDocs are generated, thus a license header is optional. >> Generated files do not require license headers. >> >> 1 Unknown Licenses >> >> * >> >> Files with unapproved licenses: >> >> src/test/resources/empty.bin >> >> * > > Q. How did you manage to get this error? > > apache-rat:check is in the default goal run by travis and > 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a while. > > I cannot reproduce this. > Curious. Not certain, but the build was with java 11. Let me start from scratch in the morning and see if I can reproduce it. If I can indeed, then I’ll send over my full mvn -version -Rob > Gary, > > I have been on holiday so have not had time to do a full RC review. I may be > able to do so in the next few days unless someone gets there first. > > Alex > > > > - > 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 Codec 1.14 based on RC1
> On 2 Jan 2020, at 16:53, Rob Tompkins wrote: > > +0 (could be convinced of +1) > > RAT: > > * > Summary > --- > Generated at: 2020-01-02T10:45:36-05:00 > > Notes: 3 > Binaries: 4 > Archives: 1 > Standards: 287 > > Apache Licensed: 286 > Generated Documents: 0 > > JavaDocs are generated, thus a license header is optional. > Generated files do not require license headers. > > 1 Unknown Licenses > > * > > Files with unapproved licenses: > > src/test/resources/empty.bin > > * Q. How did you manage to get this error? apache-rat:check is in the default goal run by travis and 'src/test/resources/empty.bin’ has been in the pom.xml exclusions for a while. I cannot reproduce this. Gary, I have been on holiday so have not had time to do a full RC review. I may be able to do so in the next few days unless someone gets there first. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
May we get more PMC reviews please? Gary On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Codec 1.13 was released, so I would like to release > Apache Commons Codec 1.14. > > Apache Commons Codec 1.14 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn > revision 37409) > > The Git tag commons-codec-1.14-RC1 commit for this RC is > af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-codec.git > --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Dec 30 19:44:19 EST 2019 > > commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf > > commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 > > commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a > > commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 > > commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b > > commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e > > commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 > > commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 > > I have tested this with: > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease > -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_231\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.13 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html > (note some *relative* links are broken and the 1.14 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.13): > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, > > 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. > > 1) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch > commons-codec-1.14-RC1 commons-codec-1.14-RC1 > cd commons-codec-1.14-RC1 > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which you > then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page which > you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page which >
NET - tftp source port check (was issue NET-414)
Folks, In https://issues.apache.org/jira/browse/NET-414 we introduced a check that the source port of a TFTP reply is not identical to the control port. Which by itself is not a bad idea. As it allows a server to handle multiple, parallel connections. It uses the port number as a session identifier (see * excerp below from Stevens, TCP/IP Illustrated, Vol1, p212). Unfortunately - this seems to break quite a few IoT implementations that bare based on LWIP, Arduino and MBed examples that do not actually pick a new/random source port. But re-use the control port (as they are only capable of one connection at the time). As they lack the memory to keep multiple bound sockets open. One example I am currently struggling with are Grbl, Saur and LAOS based laser-cutters. Now closely reading the RFC - it seems to lack the usual SHOULD or MUST (as per rfc 2119 parlance) statements around having to pick a unique/new source port that is not identical to the control port. So it seems we're a bit more strict that we should. So I am wondering if this change should be reverted; or, at the very least, be subject to a property value the end user can set system wide to `disable'. With kind regards, Dw. *: ... TFTP, the protocol is different since there is a longer term relationship between the client and server (which we said could be seconds or minutes). If one server process used the well-known port for the duration of the file transfer, it would either have to refuse any further requests that arrived from other clients, or that one server process would have to multiplex file transfers with multiple clients at the same time, on the same port (69). The simplest solution is to have the server obtain a new port after it receives the RRQ or WRQ. Naturally the client must detect this new port when it receives the first data packet and then send all further acknowledgments to that new port. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
Pardon vague.. My vote: +1 (binding) > On Jan 2, 2020, at 12:16 PM, Rob Tompkins wrote: > > +1 > >> On Jan 2, 2020, at 12:15 PM, Gary Gregory wrote: >> >> The fix would be to exclude this _test_ fixture file from the RAT check in >> the POM. >> >> Not a blocker IMO. >> >> Gary >> >> On Thu, Jan 2, 2020, 11:53 Rob Tompkins wrote: >> >>> +0 (could be convinced of +1) >>> >>> RAT: >>> >>> * >>> Summary >>> --- >>> Generated at: 2020-01-02T10:45:36-05:00 >>> >>> Notes: 3 >>> Binaries: 4 >>> Archives: 1 >>> Standards: 287 >>> >>> Apache Licensed: 286 >>> Generated Documents: 0 >>> >>> JavaDocs are generated, thus a license header is optional. >>> Generated files do not require license headers. >>> >>> 1 Unknown Licenses >>> >>> * >>> >>> Files with unapproved licenses: >>> >>> src/test/resources/empty.bin >>> >>> * >>> >>> -Rob >>> On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote: My +1 Gary On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory >>> wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Codec 1.13 was released, so I would like to release > Apache Commons Codec 1.14. > > Apache Commons Codec 1.14 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn > revision 37409) > > The Git tag commons-codec-1.14-RC1 commit for this RC is > af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: > > >>> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-codec.git > --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 > > Maven artifacts are here: > > >>> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Dec 30 19:44:19 EST 2019 > > >>> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf > > >>> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 > > >>> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a > > >>> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 > > >>> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b > > >>> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e > > >>> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 > > >>> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 > > I have tested this with: > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% >>> -Prelease > -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_231\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.13 are in the release notes: > > >>> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt > > >>> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html > > Site: > > >>> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html > (note some *relative* links are broken and the 1.14 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.13): > > >>> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
+1 > On Jan 2, 2020, at 12:15 PM, Gary Gregory wrote: > > The fix would be to exclude this _test_ fixture file from the RAT check in > the POM. > > Not a blocker IMO. > > Gary > > On Thu, Jan 2, 2020, 11:53 Rob Tompkins wrote: > >> +0 (could be convinced of +1) >> >> RAT: >> >> * >> Summary >> --- >> Generated at: 2020-01-02T10:45:36-05:00 >> >> Notes: 3 >> Binaries: 4 >> Archives: 1 >> Standards: 287 >> >> Apache Licensed: 286 >> Generated Documents: 0 >> >> JavaDocs are generated, thus a license header is optional. >> Generated files do not require license headers. >> >> 1 Unknown Licenses >> >> * >> >> Files with unapproved licenses: >> >> src/test/resources/empty.bin >> >> * >> >> -Rob >> >>> On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote: >>> >>> My +1 >>> >>> Gary >>> >>> >>> On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory >> wrote: >>> We have fixed quite a few bugs and added some significant enhancements since Apache Commons Codec 1.13 was released, so I would like to release Apache Commons Codec 1.14. Apache Commons Codec 1.14 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn revision 37409) The Git tag commons-codec-1.14-RC1 commit for this RC is af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: >> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 Maven artifacts are here: >> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ These are the artifacts and their hashes: #Release SHA-512s #Mon Dec 30 19:44:19 EST 2019 >> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf >> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 >> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a >> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 >> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b >> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e >> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 >> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 I have tested this with: mvn -V -Duser.name=%my_apache_id% -Dcommons.release-plugin.version=%commons.release-plugin.version% >> -Prelease -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy using: Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: C:\Java\apache-maven-3.6.3\bin\.. Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_231\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Details of changes since 1.13 are in the release notes: >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html Site: >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html (note some *relative* links are broken and the 1.14 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 1.13): >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html RAT Report: >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
The fix would be to exclude this _test_ fixture file from the RAT check in the POM. Not a blocker IMO. Gary On Thu, Jan 2, 2020, 11:53 Rob Tompkins wrote: > +0 (could be convinced of +1) > > RAT: > > * > Summary > --- > Generated at: 2020-01-02T10:45:36-05:00 > > Notes: 3 > Binaries: 4 > Archives: 1 > Standards: 287 > > Apache Licensed: 286 > Generated Documents: 0 > > JavaDocs are generated, thus a license header is optional. > Generated files do not require license headers. > > 1 Unknown Licenses > > * > > Files with unapproved licenses: > > src/test/resources/empty.bin > > * > > -Rob > > > On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote: > > > > My +1 > > > > Gary > > > > > > On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory > wrote: > > > >> We have fixed quite a few bugs and added some significant enhancements > >> since Apache Commons Codec 1.13 was released, so I would like to release > >> Apache Commons Codec 1.14. > >> > >> Apache Commons Codec 1.14 RC1 is available for review here: > >>https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn > >> revision 37409) > >> > >> The Git tag commons-codec-1.14-RC1 commit for this RC is > >> af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: > >> > >> > https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 > >> You may checkout this tag using: > >>git clone https://gitbox.apache.org/repos/asf/commons-codec.git > >> --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 > >> > >> Maven artifacts are here: > >> > >> > https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ > >> > >> These are the artifacts and their hashes: > >> > >> #Release SHA-512s > >> #Mon Dec 30 19:44:19 EST 2019 > >> > >> > commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf > >> > >> > commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 > >> > >> > commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a > >> > >> > commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 > >> > >> > commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b > >> > >> > commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e > >> > >> > commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 > >> > >> > commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 > >> > >> I have tested this with: > >> > >> mvn -V -Duser.name=%my_apache_id% > >> -Dcommons.release-plugin.version=%commons.release-plugin.version% > -Prelease > >> -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy > >> > >> using: > >> > >> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > >> Maven home: C:\Java\apache-maven-3.6.3\bin\.. > >> Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program > >> Files\Java\jdk1.8.0_231\jre > >> Default locale: en_US, platform encoding: Cp1252 > >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > >> > >> Details of changes since 1.13 are in the release notes: > >> > >> > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt > >> > >> > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html > >> > >> Site: > >> > >> > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html > >>(note some *relative* links are broken and the 1.14 directories are > >> not yet created - these will be OK once the site is deployed.) > >> > >> JApiCmp Report (compared to 1.13): > >> > >> > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html > >> > >> RAT Report: > >> > >> > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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... > >>
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
+0 (could be convinced of +1) RAT: * Summary --- Generated at: 2020-01-02T10:45:36-05:00 Notes: 3 Binaries: 4 Archives: 1 Standards: 287 Apache Licensed: 286 Generated Documents: 0 JavaDocs are generated, thus a license header is optional. Generated files do not require license headers. 1 Unknown Licenses * Files with unapproved licenses: src/test/resources/empty.bin * -Rob > On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote: > > My +1 > > Gary > > > On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > >> We have fixed quite a few bugs and added some significant enhancements >> since Apache Commons Codec 1.13 was released, so I would like to release >> Apache Commons Codec 1.14. >> >> Apache Commons Codec 1.14 RC1 is available for review here: >>https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn >> revision 37409) >> >> The Git tag commons-codec-1.14-RC1 commit for this RC is >> af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: >> >> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 >> You may checkout this tag using: >>git clone https://gitbox.apache.org/repos/asf/commons-codec.git >> --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 >> >> Maven artifacts are here: >> >> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ >> >> These are the artifacts and their hashes: >> >> #Release SHA-512s >> #Mon Dec 30 19:44:19 EST 2019 >> >> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf >> >> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 >> >> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a >> >> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 >> >> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b >> >> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e >> >> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 >> >> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 >> >> I have tested this with: >> >> mvn -V -Duser.name=%my_apache_id% >> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease >> -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy >> >> using: >> >> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) >> Maven home: C:\Java\apache-maven-3.6.3\bin\.. >> Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program >> Files\Java\jdk1.8.0_231\jre >> Default locale: en_US, platform encoding: Cp1252 >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >> >> Details of changes since 1.13 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html >> >> Site: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html >>(note some *relative* links are broken and the 1.14 directories are >> not yet created - these will be OK once the site is deployed.) >> >> JApiCmp Report (compared to 1.13): >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html >> >> RAT Report: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, >> >> 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
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
Just saw this. Will work on the validation over the next 30 mins. -Rob > On Jan 2, 2020, at 9:38 AM, Gary Gregory wrote: > > My +1 > > Gary > > > On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > >> We have fixed quite a few bugs and added some significant enhancements >> since Apache Commons Codec 1.13 was released, so I would like to release >> Apache Commons Codec 1.14. >> >> Apache Commons Codec 1.14 RC1 is available for review here: >>https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn >> revision 37409) >> >> The Git tag commons-codec-1.14-RC1 commit for this RC is >> af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: >> >> https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 >> You may checkout this tag using: >>git clone https://gitbox.apache.org/repos/asf/commons-codec.git >> --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 >> >> Maven artifacts are here: >> >> https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ >> >> These are the artifacts and their hashes: >> >> #Release SHA-512s >> #Mon Dec 30 19:44:19 EST 2019 >> >> commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf >> >> commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 >> >> commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a >> >> commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 >> >> commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b >> >> commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e >> >> commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 >> >> commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 >> >> I have tested this with: >> >> mvn -V -Duser.name=%my_apache_id% >> -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease >> -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy >> >> using: >> >> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) >> Maven home: C:\Java\apache-maven-3.6.3\bin\.. >> Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program >> Files\Java\jdk1.8.0_231\jre >> Default locale: en_US, platform encoding: Cp1252 >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >> >> Details of changes since 1.13 are in the release notes: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html >> >> Site: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html >>(note some *relative* links are broken and the 1.14 directories are >> not yet created - these will be OK once the site is deployed.) >> >> JApiCmp Report (compared to 1.13): >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html >> >> RAT Report: >> >> https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, >> >> 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. >> >> 1) Clone and checkout the RC tag >> >> git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch >> commons-codec-1.14-RC1 commons-codec-1.14-RC1 >> cd commons-codec-1.14-RC1 >> >> 2) Check Apache licenses >> >> This step is not required if the site includes a RAT report page which you >> then must check. >> >> mvn apache-rat:check >> >> 3) Check binary compatibility >> >> Older components still use Apache Clirr:
Re: [VOTE] Release Apache Commons Codec 1.14 based on RC1
My +1 Gary On Mon, Dec 30, 2019 at 7:59 PM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Codec 1.13 was released, so I would like to release > Apache Commons Codec 1.14. > > Apache Commons Codec 1.14 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1 (svn > revision 37409) > > The Git tag commons-codec-1.14-RC1 commit for this RC is > af7b94750e2178b8437d9812b28e36ac87a455f2 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=commit;h=af7b94750e2178b8437d9812b28e36ac87a455f2 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-codec.git > --branch commons-codec-1.14-RC1 commons-codec-1.14-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1483/commons-codec/commons-codec/1.14/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Dec 30 19:44:19 EST 2019 > > commons-codec-1.14-bin.tar.gz=bb21a15d0415513050d7738914b66bfe1f4612d7b44805ba208ec6d4fd923af244c98e828986cd4aa6cdcf9c78e23de981b5a34ac1abf805691a55f5be8cc0cf > > commons-codec-1.14-bin.zip=1119a418683ee9b599148b90056055fa93062e839ef426004c756c8054548cc1a80479f3b77a5a60c292e05ae67ae8699d46ae4ec25bad0070e17eb0e9e69756 > > commons-codec-1.14-javadoc.jar=53dda4afcd159debd68aa8b3fdb22c6de02903e725d82203db2c8692da86091a4435664eb72df12a69e65f461712435ece81da9f0658587b2f6df3991d5a048a > > commons-codec-1.14-sources.jar=a0791dacf27154fa9453e16856d5b911b568eaada52a02535bb6170bdd13e97da32051d5359aa92ad0e69948450ff6f463aedc9a04f5f9ff4d5704e31e51a6b9 > > commons-codec-1.14-src.tar.gz=1a98dc017d3213d8a89d11524683d45e9616fc6da8b4723cd1cfae23d73fefafeccc1c0f2994d1c4c52d79e1b825e4e09e601071572e2eb229105b3b4fd4a49b > > commons-codec-1.14-src.zip=0a7ebe348c9b12ee360e137c5bee833df4f7cfb259435ce6bda24073e8e1d3b76a202d4fd451efe29ddebcbcc31b3f7a287c7530d23bdc672129280d5c12d90e > > commons-codec-1.14-test-sources.jar=02c4fba74f028749abbf4bc44b328ed40fae3f60f53998dcaa2699284d337180b934ca93344271739f4e4df44643e87f7ce12dee35b252fa60f8f32ae60df460 > > commons-codec-1.14-tests.jar=18dd09a0bd91040d857d84b0be39a482e884c701bcbbb5bbba990c80cf02d0270158bdbce8fa1b4473eeeb86d03ce1c4a3232d280f8b1356ee5c9f64d8a685a8 > > I have tested this with: > > mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% -Prelease > -Pjacoco -Pjapicmp -Ptest-deploy clean package site deploy > > using: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: C:\Java\apache-maven-3.6.3\bin\.. > Java version: 1.8.0_231, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk1.8.0_231\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > Details of changes since 1.13 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/index.html > (note some *relative* links are broken and the 1.14 directories are > not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 1.13): > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/codec/1.14-RC1/site/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, > > 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. > > 1) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-codec.git --branch > commons-codec-1.14-RC1 commons-codec-1.14-RC1 > cd commons-codec-1.14-RC1 > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which you > then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page which > you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page which > you then must check. > > mvn
Re: [compress] What to do with the changed OSGi Bundle Name?
On 2020-01-02, Oliver Heger wrote: > The change of the bundle name does not necessarily break all OSGi users. > AFAIK, the recommended way to use an OSGi bundle is to import the > packages, not to require a specific bundle - this use case would not be > affected by the change of the bundle name. Ah, I see. This is backed by Julian Reschke's comment https://issues.apache.org/jira/browse/COMPRESS-498?focusedCommentId=17006749=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17006749 where he says , | same code in two different artefacts ` would be the problem. So I guess we are confusing the OSGi container if Compress 1.17 and 1.18 are available as artifacts. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with Pack200?
On 2020-01-02, Bruno P. Kinoshita wrote: > I think if we are going to release it soon, the only option to support java > 14+ the would be to remove it. Tell users it may be added back later either > as-was or as a separate artefact. If we want to cut a new release soon, we can just tell people to not use JDK 14+ when building Compress ;-) Actually I hope to release 1.20 soonish and it will still target Java 7 - as there is not reason to require more than that right now. Compress as it is can be built with any released version of Java (14 is still early access) newer than Java 6, this is good enough for now. This question - unlike the question about the OSGi bundle name is more about what happens after the next release. We could even mention our plans about pack200 with the 1.20 release notes. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with the changed OSGi Bundle Name?
Am 02.01.20 um 12:08 schrieb Bruno P. Kinoshita: > Also not a user of OSGi. But I feel like it is a bug that could be reverted > and informed in the changelog and release email? > But not too sure if that's the best option. > Bruno > > Sent from Yahoo Mail on Android > > On Thu, 2 Jan 2020 at 22:56, Stefan Bodewig wrote: Hi > all > > due to a change in the parent POM the Bundle-SymbolicName of the > commons-compress JAR changed from org.apache.commons.compress to > org.apache.commons.commons-compress with version 1.18. So we've had a > lot of releases up to 1.17 with one name and two newer releases with a > different name in 1.18 and 1.19. > > https://issues.apache.org/jira/browse/COMPRESS-498 > > Now we've got two options. > > 1. Call this a bug and revert to org.apache.commons.compress in 1.20. > > This will make users of Compress up to 1.17 happy when they upgrade. > But it alienates people who used 1.1[89], in particular if they have > already adapted to the new symbolic name. > > 2. Call this a mistake but stick to org.apache.commons.commons-compress > for 1.20 and future releases. > > This will make users of Compress up to 1.17 unhappy when they > upgrade, but makes upgrades seemless for people using 1.18 or 19. > > I'm more or less on the fence here as I'm not an OSGi user myself. > > Given that COMPRESS-498 came up more than a year after 1.18 has been > released makes me think we either haven't got many OSGi users, they > don't upgrade Compress frequently or they silently suffer and adapt to > whatever we do. The change of the bundle name does not necessarily break all OSGi users. AFAIK, the recommended way to use an OSGi bundle is to import the packages, not to require a specific bundle - this use case would not be affected by the change of the bundle name. As the change happened a while ago without major complaints, I would tend towards keeping the new name; but this is more or less a gut feeling. Oliver > > Stefan > > - > 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: [compress] What to do with Pack200?
I think if we are going to release it soon, the only option to support java 14+ the would be to remove it. Tell users it may be added back later either as-was or as a separate artefact. Just my 0.02 cents CheersBruno Sent from Yahoo Mail on Android On Thu, 2 Jan 2020 at 23:06, Stefan Bodewig wrote: Hi our travis build also uses the combination - dist: trusty jdk: openjdk-ea which has started to use OpenJDK 14 a while ago and our build has been failing there ever since. The reason is https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been removed without any replacement. AFAICT there is no (official) alternative implementation. There has been some discussion on the Eclipse lists eighteen months ago but it looks as if it never came to fruition - mostly because of legal reasons. The same legal reasons would probably apply if we resurrected the pack200 code from the atticed Apache Harmony codebase. If there was an alternative that used the same packages and APIs we could add a new dependency conditional on JDK being 1.14 or above. Without that it looks as if we had to remove the pack200 code from commons-compress and create a separate artifact for that which simply would not be built on Java 14+. Any other ideas? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] What to do with the changed OSGi Bundle Name?
Also not a user of OSGi. But I feel like it is a bug that could be reverted and informed in the changelog and release email? But not too sure if that's the best option. Bruno Sent from Yahoo Mail on Android On Thu, 2 Jan 2020 at 22:56, Stefan Bodewig wrote: Hi all due to a change in the parent POM the Bundle-SymbolicName of the commons-compress JAR changed from org.apache.commons.compress to org.apache.commons.commons-compress with version 1.18. So we've had a lot of releases up to 1.17 with one name and two newer releases with a different name in 1.18 and 1.19. https://issues.apache.org/jira/browse/COMPRESS-498 Now we've got two options. 1. Call this a bug and revert to org.apache.commons.compress in 1.20. This will make users of Compress up to 1.17 happy when they upgrade. But it alienates people who used 1.1[89], in particular if they have already adapted to the new symbolic name. 2. Call this a mistake but stick to org.apache.commons.commons-compress for 1.20 and future releases. This will make users of Compress up to 1.17 unhappy when they upgrade, but makes upgrades seemless for people using 1.18 or 19. I'm more or less on the fence here as I'm not an OSGi user myself. Given that COMPRESS-498 came up more than a year after 1.18 has been released makes me think we either haven't got many OSGi users, they don't upgrade Compress frequently or they silently suffer and adapt to whatever we do. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] What to do with Pack200?
Hi our travis build also uses the combination - dist: trusty jdk: openjdk-ea which has started to use OpenJDK 14 a while ago and our build has been failing there ever since. The reason is https://openjdk.java.net/jeps/367 - the whole Pack200 stuff has been removed without any replacement. AFAICT there is no (official) alternative implementation. There has been some discussion on the Eclipse lists eighteen months ago but it looks as if it never came to fruition - mostly because of legal reasons. The same legal reasons would probably apply if we resurrected the pack200 code from the atticed Apache Harmony codebase. If there was an alternative that used the same packages and APIs we could add a new dependency conditional on JDK being 1.14 or above. Without that it looks as if we had to remove the pack200 code from commons-compress and create a separate artifact for that which simply would not be built on Java 14+. Any other ideas? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] What to do with the changed OSGi Bundle Name?
Hi all due to a change in the parent POM the Bundle-SymbolicName of the commons-compress JAR changed from org.apache.commons.compress to org.apache.commons.commons-compress with version 1.18. So we've had a lot of releases up to 1.17 with one name and two newer releases with a different name in 1.18 and 1.19. https://issues.apache.org/jira/browse/COMPRESS-498 Now we've got two options. 1. Call this a bug and revert to org.apache.commons.compress in 1.20. This will make users of Compress up to 1.17 happy when they upgrade. But it alienates people who used 1.1[89], in particular if they have already adapted to the new symbolic name. 2. Call this a mistake but stick to org.apache.commons.commons-compress for 1.20 and future releases. This will make users of Compress up to 1.17 unhappy when they upgrade, but makes upgrades seemless for people using 1.18 or 19. I'm more or less on the fence here as I'm not an OSGi user myself. Given that COMPRESS-498 came up more than a year after 1.18 has been released makes me think we either haven't got many OSGi users, they don't upgrade Compress frequently or they silently suffer and adapt to whatever we do. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
