Re: [Numbers] First (partial) release

[Gilles]

On Thu, 10 May 2018 18:08:13 -0600, Gary Gregory wrote:
On Thu, May 10, 2018 at 5:10 PM, Gilles 


wrote:


On Thu, 10 May 2018 08:22:40 -0600, Gary Gregory wrote:


How about releasing as "beta" i.e. 1.0-beta1?



It would not reflect the real status.
As noted below, "Complex" is past beta,



Great.



while some of the
other codes need review and/or a little work to settle
known issues.



Sounds like a Beta.


To me "beta" sounds: "No _known_ issues".



Furthermore, I recall that no beta release of a Commons
project ever elicited any feedback.



So what? Getting a jar out on Maven central will give at least the 
that

opportunity.


Experience tells otherwise (about "beta" release).
But for sure, the intent is that the release would get attention
to the project.


It's better that realizing that you want some BC breaking
changes _after_ a 1.0 is out.


Back to square one: I don't want to release known unfinished
work (cf. JIRA for pending reviews) but do want to release
the supposedly stable code.

Does some policy forbid not releasing some parts of the project?
[Technically, it would be a matter of deleting the unselected
modules from the release branch.]

Gilles



Gary




Gilles


Gary


On Thu, May 10, 2018 at 7:39 AM, Gilles 


wrote:

Hi.


The modules in [Numbers] are not all in a releasable state;
even if a lot of work has been put in all of them, some
need even more to be on a par with e.g. the "Complex" class.

It doesn't seem to serve any purpose to further delay the
release as there isn't any activity towards resolving the
issues that concerns the other modules.

Thus, I'd like to release "commons-numbers-complex" (without
"ComplexUtils") and its dependencies, as well as a few other
modules which one would expect can be stable in the long run.
Will some people review the modules and afferent issues to
give an opinion on those they'd think would be ready for prime
time?

Thanks,
Gilles





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers] First (partial) release

[Gary Gregory]

On Thu, May 10, 2018 at 5:10 PM, Gilles 
wrote:

> On Thu, 10 May 2018 08:22:40 -0600, Gary Gregory wrote:
>
>> How about releasing as "beta" i.e. 1.0-beta1?
>>
>
> It would not reflect the real status.
> As noted below, "Complex" is past beta,


Great.


> while some of the
> other codes need review and/or a little work to settle
> known issues.
>

Sounds like a Beta.


>
> Furthermore, I recall that no beta release of a Commons
> project ever elicited any feedback.
>

So what? Getting a jar out on Maven central will give at least the that
opportunity. It's better that realizing that you want some BC breaking
changes _after_ a 1.0 is out.

Gary


>
> Gilles
>
>
> Gary
>>
>> On Thu, May 10, 2018 at 7:39 AM, Gilles 
>> wrote:
>>
>> Hi.
>>>
>>> The modules in [Numbers] are not all in a releasable state;
>>> even if a lot of work has been put in all of them, some
>>> need even more to be on a par with e.g. the "Complex" class.
>>>
>>> It doesn't seem to serve any purpose to further delay the
>>> release as there isn't any activity towards resolving the
>>> issues that concerns the other modules.
>>>
>>> Thus, I'd like to release "commons-numbers-complex" (without
>>> "ComplexUtils") and its dependencies, as well as a few other
>>> modules which one would expect can be stable in the long run.
>>> Will some people review the modules and afferent issues to
>>> give an opinion on those they'd think would be ready for prime
>>> time?
>>>
>>> Thanks,
>>> Gilles
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Numbers] First (partial) release

[Gilles]

On Thu, 10 May 2018 08:22:40 -0600, Gary Gregory wrote:

How about releasing as "beta" i.e. 1.0-beta1?


It would not reflect the real status.
As noted below, "Complex" is past beta, while some of the
other codes need review and/or a little work to settle
known issues.

Furthermore, I recall that no beta release of a Commons
project ever elicited any feedback.

Gilles



Gary

On Thu, May 10, 2018 at 7:39 AM, Gilles 


wrote:


Hi.

The modules in [Numbers] are not all in a releasable state;
even if a lot of work has been put in all of them, some
need even more to be on a par with e.g. the "Complex" class.

It doesn't seem to serve any purpose to further delay the
release as there isn't any activity towards resolving the
issues that concerns the other modules.

Thus, I'd like to release "commons-numbers-complex" (without
"ComplexUtils") and its dependencies, as well as a few other
modules which one would expect can be stable in the long run.
Will some people review the modules and afferent issues to
give an opinion on those they'd think would be ready for prime
time?

Thanks,
Gilles



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress] Thinking about 1.17 release

[Stefan Bodewig]

On 2018-05-10, Gary Gregory wrote:

> Maybe "User Guide" is better than "Examples".

Sounds good.

> I think we would really help out our users if the template in "Common
> Extraction Logic" would be followed by a "reference implementation", even
> if that implementation only works on one OS.

> It's better IMO if we provide copy/paste-able code instead of something
> someone will cobble up on SO and possibly get wrong.

Please have a look at the Archiver and Expander classes in the new
examples package.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-release-plugin] Next

[Gary Gregory]

On Thu, May 10, 2018 at 9:53 AM, Matt Sicker  wrote:

> On 10 May 2018 at 09:34, Gary Gregory  wrote:
>
> > Another item would be to have ONE Maven call instead of SIX for:
> >
>
> It would be great to just do "mvn release:prepare release:perform", fill
> out the release candidate version, and then have everything uploaded and
> emailed properly. Unfortunately, I'm not familiar enough with maven to know
> how to automate that sort of thing (in the past, I've usually offloaded
> that part to a CI pipeline script of some sort).
>

Right, in a dream world, there would be a simple one-liner for creating an
RC and another for promoting an RC to release.

Gary


>
>
> --
> Matt Sicker 
>

Re: [compress] Thinking about 1.17 release

[Gary Gregory]

Maybe "User Guide" is better than "Examples".

I think we would really help out our users if the template in "Common
Extraction Logic" would be followed by a "reference implementation", even
if that implementation only works on one OS.

It's better IMO if we provide copy/paste-able code instead of something
someone will cobble up on SO and possibly get wrong.

Gary

On Thu, May 10, 2018 at 9:41 AM, Stefan Bodewig  wrote:

> Hi all
>
> there haven't been any really big changes in master but I think Tika is
> waiting for COMPRESS-445 to get into a release so they can adapt their
> ZIP bomb detection mechanisms after the existing ones have been broken
> by Java10.
>
> Personally I plan to add unit tests to the archivers.examples package
> (which is at 0% coverage right now) and may merge the COMPRESS-450
> branch if/when I get feedback by the original reporter.
>
> Is there anything else you want to see inside of the next release?
>
> I've published a site build from master:
> https://stefan.samaflost.de/staging/commons-compress-1.17/
>
> Please note I've also changed quite a few things on the examples page
> https://stefan.samaflost.de/staging/commons-compress-1.17/examples.html
> during the past few days. I've split archivers and compressors and added
> a few new format-independent subsections. Maybe "examples" really isn't
> the correct text for the nav-bar link anymore. I'd appreciate feedback
> on the new text - as well as anything else.
>
> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-release-plugin] Next

[Matt Sicker]

On 10 May 2018 at 09:34, Gary Gregory  wrote:

> Another item would be to have ONE Maven call instead of SIX for:
>

It would be great to just do "mvn release:prepare release:perform", fill
out the release candidate version, and then have everything uploaded and
emailed properly. Unfortunately, I'm not familiar enough with maven to know
how to automate that sort of thing (in the past, I've usually offloaded
that part to a CI pipeline script of some sort).


-- 
Matt Sicker 

[compress] Thinking about 1.17 release

[Stefan Bodewig]

Hi all

there haven't been any really big changes in master but I think Tika is
waiting for COMPRESS-445 to get into a release so they can adapt their
ZIP bomb detection mechanisms after the existing ones have been broken
by Java10.

Personally I plan to add unit tests to the archivers.examples package
(which is at 0% coverage right now) and may merge the COMPRESS-450
branch if/when I get feedback by the original reporter.

Is there anything else you want to see inside of the next release?

I've published a site build from master:
https://stefan.samaflost.de/staging/commons-compress-1.17/

Please note I've also changed quite a few things on the examples page
https://stefan.samaflost.de/staging/commons-compress-1.17/examples.html
during the past few days. I've split archivers and compressors and added
a few new format-independent subsections. Maybe "examples" really isn't
the correct text for the nav-bar link anymore. I'd appreciate feedback
on the new text - as well as anything else.

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Collections] Release 4.2?

[Gary Gregory]

Hi All,

It looks like [collections] is in a good state for a release.

Any one want to fix bugs, go for it.

Any one want to RM, go for it.

Otherwise, I might get to it in a week or two.

Gary

Re: [commons-release-plugin] Next

[Gary Gregory]

On Thu, May 10, 2018 at 8:42 AM, Rob Tompkins  wrote:

>
>
> > On May 10, 2018, at 10:34 AM, Gary Gregory 
> wrote:
> >
> >> On Wed, May 9, 2018 at 12:06 PM, Matt Sicker  wrote:
> >>
> >>> On 9 May 2018 at 12:11, Gary Gregory  wrote:
> >>>
> >>> Also, generating the VOTE email is a minor pain and error prone. I
> >> usually
> >>> mess up the "vote ends at this date and time" part. If we do this part,
> >> we
> >>> should probably only worry about git since we just VOTEd to move
> >> everything
> >>> from svn to git.
> >>>
> >>
> >> How about just saying the vote will last at least 72 hours? Emails have
> >> timestamps in them. ;)
> >>
> >
> > Genius idea! :-)
> >
> > Another item would be to have ONE Maven call instead of SIX for:
>
> Agree on that point. I suppose we could re-work the build plugin to do all
> of those at once, or to build another target that does all of them together
> leaving the separate ones as well.
>

I think creating a _new_ target is the way to go. I am sure some RMs will
want the finer grained control.

Curious: Have you looked at that code?

Gary


>
> -Rob
>
> >
> > Update the download xml file
> >> The download page on the website is created from the file
> >> src/site/xdoc/download_{component}.xml. The XML file is created using
> mvn
> >> commons:download-page [-Dcommons.release.version=m.n]. Check that the
> >> changes (if any) are correct and commit the updated file.
> >> Update the other autogenerated files
> >> Various files are autogenerated using the commons build plugin.
> >>
> >>   - CONTRIBUTING.md - mvn commons:contributing-md
> >>
> >>
> >>   - README.md - mvn commons:readme-md
> >>
> >>
> >>   - src/site/xdoc/issue-tracking.xml - mvn commons:jira-page
> >>
> >>
> >>   - src/site/xdoc/mail-lists.xml - mvn commons:mail-page
> >>
> >> Check that the changes (if any) are correct and commit the updated
> >> file(s).
> >
> >
> >
> > Gary
> >
> >
> >>
> >>
> >> --
> >> Matt Sicker 
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-release-plugin] Next

[Rob Tompkins]

> On May 10, 2018, at 10:34 AM, Gary Gregory  wrote:
> 
>> On Wed, May 9, 2018 at 12:06 PM, Matt Sicker  wrote:
>> 
>>> On 9 May 2018 at 12:11, Gary Gregory  wrote:
>>> 
>>> Also, generating the VOTE email is a minor pain and error prone. I
>> usually
>>> mess up the "vote ends at this date and time" part. If we do this part,
>> we
>>> should probably only worry about git since we just VOTEd to move
>> everything
>>> from svn to git.
>>> 
>> 
>> How about just saying the vote will last at least 72 hours? Emails have
>> timestamps in them. ;)
>> 
> 
> Genius idea! :-)
> 
> Another item would be to have ONE Maven call instead of SIX for:

Agree on that point. I suppose we could re-work the build plugin to do all of 
those at once, or to build another target that does all of them together 
leaving the separate ones as well. 

-Rob

> 
> Update the download xml file
>> The download page on the website is created from the file
>> src/site/xdoc/download_{component}.xml. The XML file is created using mvn
>> commons:download-page [-Dcommons.release.version=m.n]. Check that the
>> changes (if any) are correct and commit the updated file.
>> Update the other autogenerated files
>> Various files are autogenerated using the commons build plugin.
>> 
>>   - CONTRIBUTING.md - mvn commons:contributing-md
>> 
>> 
>>   - README.md - mvn commons:readme-md
>> 
>> 
>>   - src/site/xdoc/issue-tracking.xml - mvn commons:jira-page
>> 
>> 
>>   - src/site/xdoc/mail-lists.xml - mvn commons:mail-page
>> 
>> Check that the changes (if any) are correct and commit the updated
>> file(s).
> 
> 
> 
> Gary
> 
> 
>> 
>> 
>> --
>> Matt Sicker 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-release-plugin] Next

[Gary Gregory]

On Wed, May 9, 2018 at 12:06 PM, Matt Sicker  wrote:

> On 9 May 2018 at 12:11, Gary Gregory  wrote:
>
> > Also, generating the VOTE email is a minor pain and error prone. I
> usually
> > mess up the "vote ends at this date and time" part. If we do this part,
> we
> > should probably only worry about git since we just VOTEd to move
> everything
> > from svn to git.
> >
>
> How about just saying the vote will last at least 72 hours? Emails have
> timestamps in them. ;)
>

Genius idea! :-)

Another item would be to have ONE Maven call instead of SIX for:

Update the download xml file
> The download page on the website is created from the file
> src/site/xdoc/download_{component}.xml. The XML file is created using mvn
> commons:download-page [-Dcommons.release.version=m.n]. Check that the
> changes (if any) are correct and commit the updated file.
> Update the other autogenerated files
> Various files are autogenerated using the commons build plugin.
>
>- CONTRIBUTING.md - mvn commons:contributing-md
>
>
>- README.md - mvn commons:readme-md
>
>
>- src/site/xdoc/issue-tracking.xml - mvn commons:jira-page
>
>
>- src/site/xdoc/mail-lists.xml - mvn commons:mail-page
>
> Check that the changes (if any) are correct and commit the updated
> file(s).



Gary


>
>
> --
> Matt Sicker 
>

Re: [Numbers] First (partial) release

[Gary Gregory]

How about releasing as "beta" i.e. 1.0-beta1?

Gary

On Thu, May 10, 2018 at 7:39 AM, Gilles 
wrote:

> Hi.
>
> The modules in [Numbers] are not all in a releasable state;
> even if a lot of work has been put in all of them, some
> need even more to be on a par with e.g. the "Complex" class.
>
> It doesn't seem to serve any purpose to further delay the
> release as there isn't any activity towards resolving the
> issues that concerns the other modules.
>
> Thus, I'd like to release "commons-numbers-complex" (without
> "ComplexUtils") and its dependencies, as well as a few other
> modules which one would expect can be stable in the long run.
> Will some people review the modules and afferent issues to
> give an opinion on those they'd think would be ready for prime
> time?
>
> Thanks,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Numbers] First (partial) release

[Gilles]

Hi.

The modules in [Numbers] are not all in a releasable state;
even if a lot of work has been put in all of them, some
need even more to be on a par with e.g. the "Complex" class.

It doesn't seem to serve any purpose to further delay the
release as there isn't any activity towards resolving the
issues that concerns the other modules.

Thus, I'd like to release "commons-numbers-complex" (without
"ComplexUtils") and its dependencies, as well as a few other
modules which one would expect can be stable in the long run.
Will some people review the modules and afferent issues to
give an opinion on those they'd think would be ready for prime
time?

Thanks,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons DBCP 2.3.0 based on RC1

[Gary Gregory]

My +1.

Gary

On Tue, May 8, 2018 at 6:08 PM, Gary Gregory  wrote:

> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons DBCP 2.2.0 was released, so I would like to release
> Commons DBCP 2.3.0.
>
> Commons DBCP 2.3.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/ (svn revision
> 26776)
>
> The tag is here:
> https://git1-us-west.apache.org/repos/asf?p=commons-dbcp.git;a=tag;h=
> 830f0bf135ebc94cec7f2700171a2850430f76f7
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/
> orgapachecommons-1326/org/apache/commons/commons-dbcp2/2.3.0/
>
> These are the Maven artifacts and their hashes
>
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar.asc
> (SHA1: 61a0593f9e79568a17cdf96a27f35a153661811e)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.jar
> (SHA1: bbb2876368ecb71f0108af1e09ceeb17b8688176)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-tests.jar.asc
> (SHA1: 9bd5ef92ff5716ca59afb64c0030d9cd1b08178b)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-tests.jar
> (SHA1: 92fc4af0d3348c715bd4d78be4fd800a84eca604)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom
> (SHA1: 8baf6f5f0083960ff08b91e173847bf7aaa6ac7c)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
> 0-test-sources.jar
> (SHA1: 74bb2457d0b523a8dd7efc2538c705ece5ac53e8)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
> 0-sources.jar.asc
> (SHA1: 6ccd175cbbbe583015db4ad3c62e9fed19b7135d)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-sources.jar
> (SHA1: fbe38b9ccf3e85b7ea712e56b2d31d9bbc775074)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
> 0-javadoc.jar.asc
> (SHA1: cc6606a256ec98028a8c357bab47dbacfdd154fe)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.
> 0-test-sources.jar.asc
> (SHA1: 5b42b57b996266d2b7804d457af094cd00a93a88)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0-javadoc.jar
> (SHA1: 0ea7fbe2914a272794befb9c98f831cc754b9e04)
> /org/apache/commons/commons-dbcp2/2.3.0/commons-dbcp2-2.3.0.pom.asc
> (SHA1: e962ee933cfeb18e1b061e3dce5e62487df958d1)
>
> I have tested this with:
>
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
> 2018-02-24T12:49:05-07:00)
> Maven home: C:\Java\apache-maven-3.5.3\bin\..
> Java version: 1.8.0_172, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_172\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Details of changes since 2.2.0 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/RELEASE-NOTES.txt
> changes-report.html in https://dist.apache.org/repos/
> dist/dev/commons/dbcp/site.zip
>
> Site:
> https://dist.apache.org/repos/dist/dev/commons/dbcp/site.zip
>   (note some *relative* links are broken and the 2.3.0 directories are
>   not yet created - these will be OK once the site is deployed)
>
>   The site contains a CLIRR report but not a JApiCmp report because I
> could not get JApiCmp to work.
>
> Clirr Report (compared to 2.2.0):
> clirr-report.html in https://dist.apache.org/repos/
> dist/dev/commons/dbcp/site.zip
>
> RAT Report:
> rat-report.html in https://dist.apache.org/repos/
> dist/dev/commons/dbcp/site.zip
>
> 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,
> i.e. sometime after 04:00 UTC 31-March 2010
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
>
> Gary Gregory
>

[GitHub] commons-text issue #82: Replace FindBugs with SpotBugs

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/82
  

[![Coverage 
Status](https://coveralls.io/builds/16920720/badge)](https://coveralls.io/builds/16920720)

Coverage remained the same at 97.833% when pulling 
**c2b3730c6701016ec6aba3566ac5c76068a49407 on PascalSchumacher:spotbugs** into 
**c54705d7969ea1a20960ea32a5cf013b4559e578 on apache:master**.



---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text pull request #82: Replace FindBugs with SpotBugs

[PascalSchumacher]

GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-text/pull/82

Replace FindBugs with SpotBugs



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-text spotbugs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-text/pull/82.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #82


commit c2b3730c6701016ec6aba3566ac5c76068a49407
Author: Pascal Schumacher 
Date:   2018-05-10T12:55:28Z

Replace FindBugs with SpotBugs




---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text pull request #81: Travis: Add Java 10 "Oracle JDK", Java 10 "Op...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/81


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org