I don't think this is a big problem. Because people can recompile the function and submit the function. Most of the computing/streaming engines ask users to recompile the jobs and resubmit the jobs when it upgrades to a new version. The best approach here is to document this behavior.
Also, if you are using Kubernetes runtime to schedule functions, you are not really impacted. - Sijie On Fri, Jul 16, 2021 at 2:44 AM Enrico Olivelli <eolive...@gmail.com> wrote: > > Hello, > I have reported this issue [1] about upgrading from Pulsar 2.7 to 2.8. > More information is on the ticket, but the short version of the story is > that > in Pulsar 2.8 we introduced a breaking change in the Schema API, by > switching SchemaInfo from a class to an interface. > > This leads to an IncompatibleClassChangeError when you have a Function or > a Connector that is using Schema.JSON(Pojo.class) and you upgrade your > Pulsar cluster (the functions worker pod for instance) from Pulsar 2.7.x to > Pulsar 2.8.0. > > The bad problem is that you cannot upgrade Pulsar without interrupting the > service and coordinating with the upgrade of the Functions. > Your functions need to be recompiled against the Pulsar 2.8 API and > deployed again in production. > > I have tried to move back SchemaInfo to an "abstract class" but without > success, because then you fall into errors. > > I am not sure there is a way to provide a good "upgrade path" for > Functions/IO users. > > If we do not find a way we have to document the upgrade in the official > Pulsar Documentation. > > We must do our best to prevent users from falling again into this bad > situation. > > Any suggestions or thoughts ? > > Regards > Enrico > > [1] https://github.com/apache/pulsar/issues/11338
