Hello.

Le lun. 17 juil. 2023 à 12:50, Elliotte Rusty Harold
<elh...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to