drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arina Ielchiieva <ar...@apache.org>
Subject Re: [DISCUSS] Deprecation policy in Drill
Date Wed, 29 Aug 2018 09:40:25 GMT
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,

On Mon, Aug 27, 2018 at 7:42 PM salim achouche <sachouche2@gmail.com> 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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message