Makes sense Abhishek, I'll work on making it backwards compatible then. Thanks, Tim
________________________________ From: Abhishek Girish <[email protected]> Sent: Thursday, September 21, 2017 3:58:55 PM To: [email protected] Subject: Re: Backwards Compatibility Policy Hey Tim, Requiring users to purge Drill's ZK data is not advisable and we might not want to go that route. We need to have a seamless upgrade path - for instance modifying values found to be in an older format to the new one, without explicit user interaction. Regards, Abhishek On Thu, Sep 21, 2017 at 3:46 PM, Timothy Farkas <[email protected]> wrote: > Hi All, > > I recently made a change to the option system which impacted the fields > contained in OptionValues and hence the format of option information we are > storing in zookeeper. So it is currently not backward compatible with old > system options stored in zookeeper. Two ways to resolve the issue are to > require old data to be purged from zookeeper when upgrading the cluster or > to attempt to allow backward compatibility by modifying the deserializer > for OptionValue. So my question is what is our stance on backwards > compatibility? > > Thanks, > Tim >
