To avoid going in circles and to summarize my 2c, I've to say I agree with James that the whole proposal and the problem description looks rather unconvincing and extraneous at best. Be so it may, extending this capability to plugins seems even more far-fetched.
- Sudheer > On Nov 22, 2016, at 12:23 PM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > In order to enable ops to experiment/test/verify the new configuration > options before upgrading to the next major version, without breaking other > people. > Note also this isn't a *replace*, it's an augmentation. The whole point is to > enable existing configuration to continue to work exactly as it did before. > If it is to be a replace across major versions this enables operations to > verify the new configuration options independently of upgrading to the new > version. The goal is to ease the pain of transition to the next major version. > > On Tuesday, November 22, 2016 1:36 PM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> wrote: > > > But, practically, on purpose, why'd you ever want to replace an existing > config setting with another new config setting in a minor release (I'm not > referring to implementation bugs)? That sort of change should belong to a > major release. The argument that it makes it easier to inherit new major > release features into LTS doesn't sound to me as strong enough reason, simply > because, presumably the new feature's default functionality should be > possible with the updating the older setting to a corresponding non-default > value in the LTS version already. > >> On Nov 22, 2016, at 9:34 AM, Alan Carroll >> <solidwallofc...@yahoo-inc.com.INVALID> wrote: >> >> Sudheer; >> "Now, let's assume the default has been changed to "thread" pool sharing in >> 5.3". >> No, let's not. That's the opposite of what I'm talking about. The entire >> point of all of this is to *NOT* change the default behavior. In fact, the >> goal is to not change behavior at all unless the administrator specifically >> and explicitly uses the new configuration variables. The reason the default >> changed was because I thought the TS-3650 mechanism already existed (e.g., >> it was detectable if the administrator used the new configuration variables >> or not). Adding that mechanism is how to avoid changing the default value >> from "global" to "thread". >> The summary is, I want to be able to experiment / add new configuration >> without changing the behavior of any existing configuration file. TS-3650 >> lets me do that in core, I want to make some minor changes to enable this in >> a plugin as well. >> >> Another example would be the change in how server ports are defined. The >> prior version used two different configuration variables while the current >> version uses just one. However, while this was changing it had no effect on >> existing configurations, which continued to behave the same as before the >> change. It would have been much easier to do that with the TS-3650 mechanism. >> James; >> I need this change to keep compatibility. So, since you're in favor of that, >> I'll take it you're OK with this change. >> >> > >
