> Luckily, it doesn't look like we ship the SLF4J API in our runtime
binaries, so we already have a situation where downstream projects can
choose the SLF4J version of both the API and provider Jars.
Ryan, this is a good point. Yes, our Spark and Flink runtime bundle jars
exclude slf4j, which is a
Sounds reasonable to me to just go to 2.x
On Mon, Sep 16, 2024 at 1:10 PM rdb...@gmail.com wrote:
> If I understand the SLF4J announcement correctly, it sounds like the best
> option is to rely on binary compatibility between the 1.x and 2.x clients.
>
> As long as we don't use the newer API, th
If I understand the SLF4J announcement correctly, it sounds like the best
option is to rely on binary compatibility between the 1.x and 2.x clients.
As long as we don't use the newer API, then the compiled code can use
either a 1.7.x or 2.0.x API Jar. The API Jar needs to match the provider
versio
Thanks Peter / Szehon,
Thank you for your interest !
> What about the conversion cost? Based on your experience, what is the
cost difference between a conversion and a full rewrite? When does it worth
to do a delete conversion, and when does it worth to do a full data rewrite?
Here is one inter
One for each Table Version? Maybe worth thinking about going forwards. We a
little discussion about this at the community sync up last weds and the
general consensus is we just keep doing things the way we are doing them
until it becomes too unwieldy, then figure out a new solution. Feel free to
st
