[GitHub] [druid] gianm edited a comment on pull request #11917: restore and deprecate AggregatorFactory methods

[GitBox <gi...@apache.org>]

gianm edited a comment on pull request #11917:
URL: https://github.com/apache/druid/pull/11917#issuecomment-967746282


   Contrarian opinion: I don't see how deferring the breaking change for 1 release helps anyone. People still need to do the work before they can upgrade to _some_ version, whether it's 0.23 or 0.24. And they won't be that far apart. So why not do the breaking change now?
   
   (On the other hand, it _would_ be helpful to defer the breaking change for a longer period, and use that time to batch it up with other breaking changes. Breaking a bunch of things all at once from time to time, and having all other releases be non-breaking, is easier for people to deal with than breaking a little bit each release. But I don't advocate this plan for reasons I get into in the rest of the comment.)
   
   The rest of this comment is a bit of soapboxing, so feel free to ignore it if you aren't into that sort of thing.
   
   The soapboxy statement is that I'm sympathetic to the Linux kernel driver school of thought when it comes to query extensions like new query types, filters, aggregators, etc. You can read about that school of thought here: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html. There's a very abbreviated TLDR right there in the URL.
   
   In our situation, maintaining stability for query extensions has upsides that affect a relatively small number of sites where there are site-specific query extensions in play, but has downsides that affect all sites.
   
   The main downside of maintaining stable interfaces is that it creates extra work. For example: it's common for us to add a method that gets some new information that query engines will use to make better decisions. Supporting a stable interface means we need to include handling for that information being unknown. On the other hand, if we break the interface then we can also get rid of the code that handles the "unknown" case. It simplifies the core, reduces the surface area that needs to be tested and maintained, and makes the user experience more uniform, all of which are good things.
   
   Being more free with changing these interfaces would help us evolve them faster, and would benefit the majority of sites that _don't_ have their own site-specific extensions. And just like in Linux, if people with site-specific extensions get tired of maintaining them, that problem can be solved by contributing them to mainline in extensions-contrib.
   
   Btw, a coda. Our equivalent of the Linux kernel _syscall_ API (which is famously stable) is our HTTP APIs and query API. I am sympathetic to the Linux view there too, and I kind of wish they were _more_ stable than they are.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org