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.
> 
> 

Reply via email to