Sorry, I did find your email which I have seemingly missed with: >
Thanks :-) > > To summarise, we need to make 4.2 into 5.0, as > > - we need to remove (the already deprecated) JavaScript UDFs to add JDK > 17, > > - dropping support for JDK8 would make it impossible to upgrade from 3.x > (see explanation below), > > - CEP-21 (once accepted) will be easier without having to support 3.x > compatibility. It is also my understanding that CEP-15 requires CEP-21. > > At least from my perspective, I would not bump the version just because of > UDFs and JDK 8. > WRT to JDK 8 that was my original opinion. But the more I thought about what Jeremiah wrote, the more I realised how uncomfortable (and how I would struggle to professionally recommend to a customer under paid consulting) to upgrade a cluster from 3.x JDK 8 nodes to trunk JDK 11 nodes. We should be encouraging users to update (e.g. upgrade JDK) their systems between upgrades, and definitely not forcing them to do so at and during upgrades. The removal of deprecated stuff (e.g. JavaScript UDFs) is a simplification and signal to operators, one that also aligns with the "get your system up to date before the major upgrade". So again… I'm banging on about taking advantage of creating a distinction between major/minor that benefits operators. Yes we have things like the amoeba effect (compatibility isn't obvious after all), but there are separate tactics to deal with that, though some structure and precedence does help a lot.
