You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Elliotte Rusty Harold <el...@ibiblio.org> on 2023/07/17 10:49:13 UTC
Move NO algorithms from ANY projects to math libraries
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 with the same signature
indefinitely. Compatibility is far more important than consistency. Do
NOT redesign or rethink the APIs at this late date. Too much depends
on them.
New methods, classes, and packages, and projects can be added where
appropriate. Internals can be improved as possible. But what's there
today stays there, absent the very rare case where critical bugs or
security issues require breaking an API. However, that's extremely
uncommon.
No API will ever be perfect or free from hindsight. But the cost of
change is too high to justify breaking commons libraries. Stare
decisis is as valuable a principle in API design as in law.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
Posted by Gary Gregory <ga...@gmail.com>.
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 <md...@apache.org> wrote:
> 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 <se...@gmail.com> wrote:
>
> > On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold <el...@ibiblio.org>
> > wrote:
> > >
> > > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> > > <ef...@gmail.com> 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 not change.
> > > Group and artifact IDs must not change.
> > > Split packages are not allowed.
> >
> > +1
> >
> > > --
> > > Elliotte Rusty Harold
> > > elharo@ibiblio.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: Move NO algorithms from ANY projects to math libraries
Posted by Mike Drob <md...@apache.org>.
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 <se...@gmail.com> wrote:
> On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
> >
> > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> > <ef...@gmail.com> 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 not change.
> > Group and artifact IDs must not change.
> > Split packages are not allowed.
>
> +1
>
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Move NO algorithms from ANY projects to math libraries
Posted by sebb <se...@gmail.com>.
On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold <el...@ibiblio.org> wrote:
>
> On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> <ef...@gmail.com> 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 not change.
> Group and artifact IDs must not change.
> Split packages are not allowed.
+1
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
Posted by Dimitrios Efthymiou <ef...@gmail.com>.
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, <el...@ibiblio.org>
wrote:
> On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> <ef...@gmail.com> 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 not change.
> Group and artifact IDs must not change.
> Split packages are not allowed.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Move NO algorithms from ANY projects to math libraries
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
<ef...@gmail.com> 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 not change.
Group and artifact IDs must not change.
Split packages are not allowed.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
Posted by Dimitrios Efthymiou <ef...@gmail.com>.
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 <el...@ibiblio.org>
wrote:
> 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 with the same signature
> indefinitely. Compatibility is far more important than consistency. Do
> NOT redesign or rethink the APIs at this late date. Too much depends
> on them.
>
> New methods, classes, and packages, and projects can be added where
> appropriate. Internals can be improved as possible. But what's there
> today stays there, absent the very rare case where critical bugs or
> security issues require breaking an API. However, that's extremely
> uncommon.
>
> No API will ever be perfect or free from hindsight. But the cost of
> change is too high to justify breaking commons libraries. Stare
> decisis is as valuable a principle in API design as in law.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Move NO algorithms from ANY projects to math libraries
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le lun. 17 juil. 2023 à 12:50, Elliotte Rusty Harold
<el...@ibiblio.org> 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 do that in every major release. Otherwise it wouldn't
be a major release.
> Every method and class that currently exists in any
> commons library should continue to exist there with the same signature
> indefinitely.
It does, but in outdated (and often unsupported) older versions.
Parties that want it otherwise should provide the necessary
resources (e.g. to maintain older versions).
> Compatibility is far more important than consistency.
There has never been any (intentional) breaking of (binary)
compatibility in a minor release.
> Do
> NOT redesign or rethink the APIs at this late date. Too much depends
> on them.
That depends on which component(s) you are talking about.
and which versions and whether it is "beta" or not.
>
> New methods, classes, and packages, and projects can be added where
> appropriate. Internals can be improved as possible. But what's there
> today stays there, absent the very rare case where critical bugs or
> security issues require breaking an API. However, that's extremely
> uncommon.
It has been the "Commons" policy for years.
> No API will ever be perfect or free from hindsight. But the cost of
> change is too high to justify breaking commons libraries.
No one is forced to use the latest versions.
> Stare
> decisis is as valuable a principle in API design as in law.
Not following the advice led to [RNG], [Numbers], [Geometry]
and [Statistics], all of which could challenge previous decisions,
resulting in better API, more functionality, improved performance,
bugs discovery...
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org