We will NEVER drop the support of OpenResty. APSIX is based on OpenResty. You can add patches on OpenResty, but it is not drop.
Thanks, Ming Wen, Apache APISIX PMC Chair Twitter: _WenMing wei liu <monkeydluffy6...@gmail.com> 于2023年8月4日周五 17:09写道： > LGTM > > On Fri, Aug 4, 2023 at 5:04 PM Xin Rong <alins...@apache.org> wrote: > > > In the earliest versions, APISIX used Openresty as the runtime, but > > OpenResty often failed to meet APISIX's scalability needs. To solve > > this problem, we built apisix-base and have been running on it for > > over a year. > > > > > > For example, these features can only run in the apisix-base environment: > > > > * upstream.tls: Enables secure communication between APISIX and > > upstream servers. > > * etcd.tls: Enables secure communication between APISIX and etcd > clusters. > > * xrpc/redis: The Redis protocol support allows APISIX to proxy Redis > > commands, and provide various features according to the content of the > > commands. > > * Dubbo proxy: Supports proxying Apache Dubbo requests. > > * client-control Plugin: The client-control Plugin can be used to > > dynamically control the behavior of NGINX to handle a client request, > > by setting the max size of the request body. > > * Gzip Plugin: The gzip Plugin dynamically sets the behavior of gzip in > > Nginx. > > * Wasm Plugin: Allows loading and running WebAssembly modules in APISIX. > > * Prometheus Plugin: Optimizing long tail requests caused by excessive > > data volume in metrics. > > * proxy-control Plugin: The proxy-control Plugin dynamically controls > > the behavior of the NGINX proxy. > > * Real-ip Plugin: The real-ip Plugin is used to dynamically change the > > client's IP address and port as seen by APISIX. > > > > > > Although we still retain compatibility with OpenResty, in practice, > > the incompatibility issues between APISIX and OpenResty are often > > unresolved. Our usual approach is to skip these issues. Considering > > that APISIX will continue to add new features and bug fixes in the > > future, these features are often not supported in native OpenResty. At > > the same time, we also need to consider compatibility with OpenResty, > > which requires extra maintenance work in testing and development. > > > > > > By dropping support for OpenResty, we can remove extra CI jobs and > > version checks, making the code simpler. > > > > What about your opinion? > > >
