Yes you’re totally welcome to, and the directions are here: http://commons.apache.org/releases/index.html <http://commons.apache.org/releases/index.html>
Feel free to ask questions and I would suggest using the release plugin portion of the release preparation page. If there’s confusion (I would expect some obsolescence) on the page do make note of it, and I would be happy to update it as we see fit. All the best, -Rob > On Mar 24, 2020, at 9:26 AM, Matt Juntunen <matt.juntu...@hotmail.com> wrote: > > Hello, > > Am I able to perform this beta release of numbers now that I am a committer? > If so, how would I go about it? > > Thanks, > Matt > ________________________________ > From: Matt Juntunen <matt.juntu...@hotmail.com> > Sent: Saturday, March 7, 2020 7:37 AM > To: Alex Herbert <alex.d.herb...@gmail.com>; Commons Developers List > <dev@commons.apache.org> > Subject: Re: [numbers] Release? > > Hello, > > Any progress here? > > Regards, > Matt > ________________________________ > From: Alex Herbert <alex.d.herb...@gmail.com> > Sent: Friday, February 21, 2020 8:20 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: [numbers] Release? > > > >> On 22 Feb 2020, at 01:15, Gilles Sadowski <gillese...@gmail.com> wrote: >> >> Le sam. 22 févr. 2020 à 01:30, Alex Herbert <alex.d.herb...@gmail.com >> <mailto:alex.d.herb...@gmail.com>> a écrit : >>> >>> >>> >>>> On 22 Feb 2020, at 00:29, Gilles Sadowski <gillese...@gmail.com> wrote: >>>> >>>> Hi. >>>> >>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen >>>> <matt.juntu...@hotmail.com> a écrit : >>>>> >>>>> Are we waiting on anything for a numbers release? >>>> >>>> I don't think so. >>> >>> Are you talking about a beta release where the API is not yet frozen? >> >> Yes. >> >>> I’m still testing versions of LinearCombination. But from the discussion on >>> NUMBERS-142 [1] it seems the choice may be to just change the current class >>> to use a more precise method. It will be slower than the current method but >>> will have an ensured accuracy of 1 ULP. It will be much faster than >>> BigDecimal. All the testing implementations can go into the examples module >>> for reference. >>> >>> I have 1 PR for Complex to add an internal version of Math.hypot >>> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster >>> and more accurate than Math.hypot. >>> >>> I think Complex is ISO C99 compliant and quite robust to edge cases. The >>> javadoc needs a second pass and then an internal rearrangement of the code >>> layout. I’ve left this until last so that the git change history is clear. >>> But the methods and API are done. >>> >>> Then there is the implementation of ComplexList for storing and working >>> with many complex numbers. This would be a replacement for part of >>> numbers.complex.stream.ComplexUtils. The question is should this part of >>> the API be established before any release? If a beta then we can remove >>> redundant methods from ComplexUtils later. >> >> I would not include the "commons-numbers-complex-streams" module >> (IIRC you mentioned that for performance, "ComplexList" should be in >> the same module as "Complex”). > > Yes. I think a lot of the private methods in Complex would have to be > promoted to package private for reuse so many of the functions could operate > without having to actually create an instance of Complex. > > That would be my suggestion. Since the beta release would be on a fork we can > delete the module from the fork. Then it can be sanitised in master when > appropriate. > >> >> Regards, >> Gilles >> >>> >>> Alex >>> >>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# >>> <https://issues.apache.org/jira/browse/NUMBERS-142#> >>> <https://issues.apache.org/jira/browse/NUMBERS-142# >>> <https://issues.apache.org/jira/browse/NUMBERS-142#>> >>> >>> >>>> >>>> Best, >>>> Gilles >>>> >>>>> >>>>>> [...] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> <mailto:dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> <mailto:dev-h...@commons.apache.org>
