The conflict is in the solution being proposed - AFAICT, merely not specifying a config setting explicitly in records.config does NOT mean, the resultant (default) behavior can be changed in a minor release update.
For example, take the case of server session sharing that was the origin of the whole discussion. Let's say, 5.0 had a default of "global" server session sharing. Whether or not a specific deployment explicitly set server session sharing to global or not in records.config, the behavior they'd see is still global sharing (which has a certain noticeable external impact - example, number of origin connections, latency etc). Now, let's assume the default has been changed to "thread" pool sharing in 5.3. Simply because, some deployment did not specify explicitly that they wanted global sharing in records.config, they'd now start seeing a noticeable impact when updating to 5.3 because the default has been changed. To me, this clearly sounds like a "break" across minor update. It is at least not "seamless" as we claimed officially. The right thing to do would be to maintain the default to global across all 5.x and if needed and agreed, the default can be changed in 6.0. The change in default would be documented in the release notes for 6.0 along with the expectation that when an administrator updates to 6.0, incompatible behavior changes are possible and the documentation provides the necessary warnings or mechanisms to address the consequences. With the solution proposed, essentially, you are allowing any setting to change its default *anytime* and the only way one can guarantee the existing behavior is to manually/explicitly add the setting with the default in records.config even for minor release updates. This to me doesn't sound like a clean path (it's at least not what we claim officially as I read it). Also, I still can't think of any other instances other than TS-3650 (which I argue is a direct consequence of a mere implementation bug) where this kind of change in default should be required or encouraged. Having this in core was probably not desirable to begin with, and now exposing it to plugins might make things even worse. - Sudheer > On Nov 22, 2016, at 8:50 AM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > I don't see the conflict with the policy you quoted. Use of the config > variable source mechanism means that new configuration options can be added > to minor versions because it can be done without an incompatible change, > exactly in line with "MINOR version when you add functionality in a > backwards-compatible manner". I think the ability to have a smoother > transition, where configuration changes are enabled but not required, is very > nice for the people who actually deploy ATS. > But the real local issue here is, should we have the TS-3650 mechanism only > for core and not for plugins? What is the justification for having it not > work only for plugins? > >
