Hi,
gentle ping on this thread that I posted a FLIP proposal in a new
thread about this [1].
Thanks,
Ferenc
[1] https://lists.apache.org/thread/dlkmgdtkh6w8f6s5dmsfm4jb5tgmj63q
On Wednesday, 24 July 2024 at 03:39, Xintong Song wrote:
>
>
> Sounds good to me. Thank you, Ferenc.
>
>
> Be
Sounds good to me. Thank you, Ferenc.
Best,
Xintong
On Tue, Jul 23, 2024 at 9:42 PM Ferenc Csaky
wrote:
> > IIUC, you mean applying the strict mode for the programming APIs
> > as well?
>
> Correct! The original thought that came to my mind that this could
> be achieved with something simil
> IIUC, you mean applying the strict mode for the programming APIs
> as well?
Correct! The original thought that came to my mind that this could
be achieved with something similar to the "jdeprscan" Java tool,
that checks for deprecated usage. In our case, the presence of
@Deprecated and @Public o
>
> As I think about it, most likely orthogonal to the current
> discussion, but this idea seems to be applicable for the
> submitted job JARs as well. The same check could be done for all
> the submitted files and their deps. IDK if that was your original
> thought Xintong or not?
>
IIUC, you mea
Hi Xintong, Muhammet,
Thank you for your thoughts!
I agree with Xintong regarding 1), and 2).
About making users aware of these compatibility guarantees,
documentation and CLI print deprecation is what I already aimed
for when I was merging the "run" and "run-application" actions
functionality [
I think there are three questions to be anwsered, and here are my two cents.
1) How do we define the compatibility guarantees for cli interfaces?
I'd be +1 for reusing the existing @Public and @PublicEvolving annotations,
as suggested by Ferenc. Having multiple sets of rules in the same project
m
Hey Ferenc,
Yes correct. My thoughts were based on finding tradeoff between
following fully deprecation process and leaner one for CLIs.
Since cli are not like APIs, I think users would be aware of
deprecation only when were remove the commands. That is they
try to run their jobs with upgrade an
Hi Muhammet,
Thank you for your thoughts!
> After two minor releases, and on next major version bump,
> we could drop the `run-application` method as suggested
> on discussion by Xintong.
Here, you describe the deprecation/removal process of a public
API by the definition we have in the project
Hey Ferenc,
Thanks for starting the discussion!
I agree that the CLI is user facing, but I think we don't
have to treat it as other public APIs.
I'd propose to throw user friendly exception for
`run-application` with suggestion to use `run` case instead.
This would make users aware of the chang
Hello devs,
I would like to open a discussion about considerations regarding how to
deprecate CLI
actions, and what compatibility guarantees should apply to such cases. The
topic came up in
a previous discussion [1] about a current FLIP to merge the run and
run-application
behavior [2].
Accordi
10 matches
Mail list logo
