Re: Move NO algorithms from ANY projects to math libraries
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 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
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 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, 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 not change. > > > Group and artifact IDs must not change. > > > Split packages are not allowed. > > > > +1 > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: Move NO algorithms from ANY projects to math libraries
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 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 not change. > Group and artifact IDs must not change. > Split packages are not allowed. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: Move NO algorithms from ANY projects to math libraries
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, 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 not change. > > Group and artifact IDs must not change. > > Split packages are not allowed. > > +1 > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: Move NO algorithms from ANY projects to math libraries
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. > > 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 > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
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 not change. Group and artifact IDs must not change. Split packages are not allowed. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Move NO algorithms from ANY projects to math libraries
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 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 > elh...@ibiblio.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
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 elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
