Hi Chesnay, I am trying to understand what is the right removal process with this concrete example. Given all things about the programArgs are private or package private except the constructor. Will you just mark it as deprecated with constructor overloading in 1.18 and remove it in 2.0? Should we describe the deprecation work in the FLIP?
Another more general question, maybe offtrack, I don't know which thread is the right place to ask, since Java 11 has been recommended, should we always include "since" and "forRemoval" while adding @Deprecated, i.e. ArchUnit rule? Best regards, Jing On Mon, Jul 17, 2023 at 5:33 AM Xintong Song <tonysong...@gmail.com> wrote: > +1 > > Best, > > Xintong > > > > On Thu, Jul 13, 2023 at 9:34 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > Hello, > > > > The request body for the jar run/plan REST endpoints accepts program > > arguments as a string (programArgs) or a list of strings > > (programArgsList). The latter was introduced as kept running into issues > > with splitting the string into individual arguments./ > > / > > > > We ideally force users to use the list argument, and we can simplify the > > codebase if there'd only be 1 way to pass arguments. > > > > As such I propose to remove the programArgs field from the request body. > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263424796 > > > > > > Regards, > > > > Chesnay > > >
