Closed HiGarfield closed 1 year ago
I don't get it. It will make users to be confused. Are those config too good to be updated? Changes are more than this. If you use the new version, you should update your config.
I don't get it. It will make users to be confused. Are those config too good to be updated? Changes are more than this. If you use the new version, you should update your config.
In my case, the package s-~sr~-pro in OpenWrt generates old style config for dnsforwarder and then call dnsforwarder. The config is automatically generated by a script rather than manually defined. When dnsforwarder is updated to the latest version, s-~sr~-pro stops working due to the failure of dnsforwarder. I have to use a patch generated from this commit to keep it working.
Moreover, this patch makes dnsforwarder compatible with both old-style and new-style configs.
That is also why I'm not going to adopt this compatibility. Despite it makes code more complicated, it makes users unconscious about the real behavior changes of the new version, which will produce unexpected results and issue reports. It is not the right direction.
That is also why I'm not going to adopt this compatibility. Despite it makes code more complicated, it makes users unconscious about the real behavior changes of the new version, which will produce unexpected results and issue reports. It is not the right direction.
OK. I can just put this patch downstream.
Due to the usage with old programs (e.g., luci-app-dnsforwarder in OpenWrt), dnsforwarder needs to be compatible with old-style config files.
old-style format: TCPGroup <IP1[:PORT],IP2[:PORT],...> <DOMAIN1,DOMAIN2,...> <no|PROXY1[:PORT],PROXY2[:PORT],...>