Hi all, thanks for your feedback. Looks like the majority here is considering Drill options and tables as part of API. Based on that when we deprecate any of such notions we should not remove them to ease updates and not break backward compatibility. Though when Drill will move to 2.0 (which is next major version, not ETA yet) where API might be changed, deprecated notions should be considered to be removed as well. Does this sound reasonable?
Kind regards, Arina On Mon, Aug 27, 2018 at 7:42 PM salim achouche <[email protected]> wrote: > Drill is a SQL engine, which means the SQL syntax and associated options > (runtime configuration and session properties) constitute its user facing > APIs (if I may say). When we talk about deprecating and then removing > documented session / configuration properties within the same release, then > what does the versioning scheme mean? are we suggesting that: > - Options are not part of the main Drill APIs? > - It is ok to deprecate and then rename such properties (not remove)? > - It is ok to deprecate and then remove existing properties as long as > there is no change in behavior? >
