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 <seb...@gmail.com> wrote: > > > On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > > > > > > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou > > > <efthymiou.dimitri...@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 > > > 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 > > > > >
