> - If we support 2.0+ to 4.0 client/KS upgrade it's simpler, but of course > brokers cannot be 4.0 yet -- but I guess this would be something natural? > Given that the clients would be on 2.0, brokers cannot be 4.0 yet, or clients > would have crashed already... Thus, I think I slightly prefer this one.
Using a major version as a bridge is a viable approach. We can emphasize the limitations of this method to guide users in selecting the most suitable bridge version. > For KS, from an API compatibility POV, upgrading from anything older than 3.6 > might not work any longer (for DSL users; of course, depending on what APIs > they are using). And for PAPI, the old API was removed too, so only if the > new one is use (introduced in 2.7) a seamless upgrade would work smoothly. You make a valid point. The previous discussion overlooked the APIs that were removed in version 4.0. We could also emphasize the BC advantages. As an example, users have the option of using version 2.7 as a bridge and subsequently upgrade without code alterations or recompilation. Of course, we need to check the version of other PAPI removal. Best, Chia-Ping > Matthias J. Sax <mj...@apache.org> 於 2025年1月22日 凌晨2:55 寫道： > For KS, from an API compatibility POV, upgrading from anything older than 3.6 > might not work any longer (for DSL users; of course, depending on what APIs > they are using). And for PAPI, the old API was removed too, so only if the > new one is use (introduced in 2.7) a seamless upgrade would work smoothly.
