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 <[email protected]> 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 <[email protected]> wrote:
>
> > On Mon, 17 Jul 2023 at 14:31, Elliotte Rusty Harold <[email protected]>
> > wrote:
> > >
> > > On Mon, Jul 17, 2023 at 9:21 AM Dimitrios Efthymiou
> > > <[email protected]> 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
> > > [email protected]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to