Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread sebb
On 30 July 2017 at 16:30, Matt Sicker wrote: > If the build is anything like Log4j's, it probably has a separate rat > config for the release profile than it does by default. If rat and Clirr are run as part of the the site build they use the report settings whereas 'mvn clirr:check' will use the

Re: Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)

2017-07-30 Thread Gary Gregory
On Sun, Jul 30, 2017 at 8:37 AM, Simon Spero wrote: > Class file format is not treated as a breaking change under most versioning > approaches, including the JLS. > > The checkers I looked at that reported on class file format changes > consider it a micro level version change (+0.0.1) > > The

Language level, Class files, MRJARs & versioning (was Re: [collections][proposal] Java 7)

2017-07-30 Thread Simon Spero
Class file format is not treated as a breaking change under most versioning approaches, including the JLS. The checkers I looked at that reported on class file format changes consider it a micro level version change (+0.0.1) The past few major version bumps for projects I've worked happened to

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Matt Sicker
If the build is anything like Log4j's, it probably has a separate rat config for the release profile than it does by default. On 30 July 2017 at 10:27, Gary Gregory wrote: > I always run: > > mvn apache-rat:check > > And > > mvn clirr:check > > Gary > > On Jul 30, 2017 07:12, "Stefan Bodewig" w

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Gary Gregory
I always run: mvn apache-rat:check And mvn clirr:check Gary On Jul 30, 2017 07:12, "Stefan Bodewig" wrote: > On 2017-07-30, Gary Gregory wrote: > > > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > > Email Package" instead of "Commons Email Package". > > I was under

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Stefan Bodewig
On 2017-07-30, Amey Jadiye wrote: > I have fixed this, and yes reason was though those .eml files was added in > exclusion but in reports and not in build. > I have raised PR and tested it on my local. > https://github.com/apache/commons-email/pull/2 LGTM, but please allow us to get the release

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Amey Jadiye
Hi, I have fixed this, and yes reason was though those .eml files was added in exclusion but in reports and not in build. I have raised PR and tested it on my local. https://github.com/apache/commons-email/pull/2 Regards, Amey On Sun, Jul 30, 2017 at 7:42 PM, Stefan Bodewig wrote: > On 2017-0

Re: [email] failing with mvn clean cobertura:cobertura coveralls:report

2017-07-30 Thread Stefan Bodewig
On 2017-07-30, Amey Jadiye wrote: > while fixing rat issue with commons email I also found that the travis is > failing with the below configurations, thought build is working fine. > seems like we dont have plugin configured in pom.xml > after_success: > - mvn clean cobertura:cobertura covera

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Stefan Bodewig
On 2017-07-30, Gary Gregory wrote: > Branding: The RELEASE-NOTES.txt file should start with "Apache Commons > Email Package" instead of "Commons Email Package". I was under the impression it had been generated by the commons-build plugin. Anyway, will fix it when I publish the release (no reason

[email] failing with mvn clean cobertura:cobertura coveralls:report

2017-07-30 Thread Amey Jadiye
Hi, while fixing rat issue with commons email I also found that the travis is failing with the below configurations, thought build is working fine. seems like we dont have plugin configured in pom.xml after_success: - mvn clean cobertura:cobertura coveralls:report [INFO]

Re: [VOTE] Release Commons Email 1.5 Based on RC1

2017-07-30 Thread Amey Jadiye
Checked RC1, and here is my +1 (non-binding). 1. Build and Tests looks good. 2. Clirr looks good. 3. Rat is not good as mentioned by gary, as they are test resources can be put to ignore list. 4. Findbug looks good. 5. There are 302 Checkstyle issues but they are non-blocker to release. 6. Hashes

[GitHub] commons-codec pull request #4: commons-codec

2017-07-30 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/commons-codec/pull/4 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] commons-codec pull request #1: More tests

2017-07-30 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/commons-codec/pull/1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] commons-text pull request #58: Add tests

2017-07-30 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/commons-text/pull/58 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] commons-text issue #58: Add tests

2017-07-30 Thread PascalSchumacher
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-text/pull/58 Thanks! :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wish