Hello.
Le lun. 17 juil. 2023 à 12:50, Elliotte Rusty Harold
a écrit :
>
> There are a lot of proposals floating recently to churn the API. I'm
> going to move a direct no on all of this.
>
> Mild improvements in consistency in no way justify any API breakage or
> even deprecation.
We routinely d
No proxying please. Usually "moving" means deprecating and removing in the
next major version or never. Other components can add whatever they best
see fit regardless of whether something's been deprecated elsewhere or not.
Gary
On Mon, Jul 17, 2023, 12:49 Mike Drob wrote:
> Can we move impleme
Nothing will change then. Agreed. If you have a class MathUtils and a
method add(double... numbers) then keep it, but replace the body if the
method with the call to commons-numbers, for example. That's what I mean
On Mon, 17 Jul 2023, 14:31 Elliotte Rusty Harold,
wrote:
> On Mon, Jul 17, 2023 a
Can we move implementations, have old definitions be thin proxies to the
new locations, mark existing methods as deprecated, and document that
future development happens somewhere else?
On Mon, Jul 17, 2023 at 9:55 AM sebb wrote:
> On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold
> wrote:
>
On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold wrote:
>
> On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> wrote:
> >
> > hello. I never said to redesign APIs. I only said that we can
> > move math algorithms from non-math projects, to the math projects
> >
>
> No, don't do that.
>
> Me
On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
wrote:
>
> hello. I never said to redesign APIs. I only said that we can
> move math algorithms from non-math projects, to the math projects
>
No, don't do that.
Method signatures must not change.
Class names must not change.
Package names must
hello. I never said to redesign APIs. I only said that we can
move math algorithms from non-math projects, to the math projects
On Mon, 17 Jul 2023 at 11:50, Elliotte Rusty Harold
wrote:
> There are a lot of proposals floating recently to churn the API. I'm
> going to move a direct no on all of
There are a lot of proposals floating recently to churn the API. I'm
going to move a direct no on all of this.
Mild improvements in consistency in no way justify any API breakage or
even deprecation. Every method and class that currently exists in any
commons library should continue to exist there
