I think that there are two different points that we need to think of. 1. minimize the user impact using canary, early detect the issue by improving the testing (e.g. setting up perf cluster with representative production use cases): I think that we all agree on this point. @LinkedIn, we already have the canary mechanism and we also do have a plan to further improve our testing pipeline for internal use cases to be able to detect the issue much earlier. 2. pinot community’s stance on backward incompatible changes: As Pinot gets mature, we should definitely be careful about the backward compatibility because this will increase the complexity for users when they upgrade the versions. I do agree that breaking backward compatibility should be evaluated based on the cost of upgrade vs benefit that the change will bring into, not based on the risk of LinkedIn deployment. As long as the backward incompatible changes are correctly applied (keep both behaviors -> kill the old behavior later), we do not have any problem with it. But many times, we’ve had many production issues because some commits broke the backward compatibility within the same version, which is not the expected behavior. This is something that we as a community should put the effort to improve.