Here's what curl says about its upgrade policy - https://curl.haxx.se/libcurl/abi.html
"In the vast majority of all cases, a typical libcurl upgrade does not break the ABI at all. Your application can remain using libcurl just as before, only with less bugs and possibly with added new features. You need to read the release notes, and if they mention an ABI break/soname bump, you may have to verify that your application still builds fine and uses libcurl as it now is defined to work." Here's what Trafiicserver says - https://docs.trafficserver.apache.org/en/latest/admin-guide/installation/index.en.html?highlight=compatibility "Traffic Server Versioning Before you get started with Traffic Server you may have to decide which version you want to use. Traffic Server follows the Semantic Versioning guidelines." "http://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format." IMHO, we should try to stick to our policies for version updates as far as possible and avoid unnncessary complexities or inconsistent/non-uniform behavior to the one we claim officially. I still think TS-3650 was a result of an implementation error that unfortunately overlooked backward compatibility and resulted in a breakage across minor version update. And to my knowledge, there really was no intention to break it on purpose nor there has been another instance where this happened. IOW, I view TS-3650/TS-3642 etc as simple bug fixes and something that should not recur. We have generally been very diligent and successful at discouraging when proposals to change defaults or behavior within a major release come along. I see no reason to go back on that policy purely based on one erroneous implementation (which could have easily been reversed rather than invent another mechanism to seemingly encourage that behavior more consistently). And if we did, it probably is a much larger scope discussion and may involve other things besides config default changes. You mentioned adoption of new major version within an LTS release as a reason to support this functionality - I am not sure that's a strong enough justification, since generally, the new default can likely be achieved by overriding the default in LTS already (otherwise, the functionality that the new default provides is not possible at all in the LTS release). Again, I think all of this comes down to whether we want to encourage this sort of behavior changes (changing defaults) across minor updates and I'd think not and it can wait for the next major update typically. - Sudheer
