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,
Gr
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 revi
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
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
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
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
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
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 pac
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
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 e
> 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 t
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 abo
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
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
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:
>
Github user coveralls commented on the issue:
https://github.com/apache/commons-text/pull/82
[](https://coveralls.io/builds/16920720)
Coverage remained the same at 97.833% when pulling
**c2b3730c6701016ec6aba3
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
Alternative
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
18 matches
Mail list logo
