> On Nov 22, 2016, at 6:25 AM, Alan Carroll 
> <solidwallofc...@yahoo-inc.com.INVALID> wrote:
> 
> "If `proxy.config.james` supersedes the old configuration, I should not have 
> to explicitly specify it in records.config for that to work"
> Correct. And if the administrator specifies no configuration variable, that's 
> what happens. If the administrator does specify it, then it works. The case 
> of interest is where the administrator does NOT specify the new configuration 
> value and DOES specify the old one. In that case I think it's clear the 
> administrator expects the old setting to work. Your argument is the 
> administrator did that in order to get the default behavior of the new 
> configuration setting?

No, my argument is that you can’t read too much into this. If you want to keep 
compatibility, great, keep it. You can’t tell whether an operator depends on a 
config value by looking at whether they used the default or specified it in 
records.config.

> My experience in actually deploying stuff and working with those who do is 
> this sort of backwards compatibility is highly valued. It makes rolling out 
> new versions much easier. It also seems a common thing to do - look at curl 
> parameters for instance, where old switches are maintained while providing 
> newer equivalent ones.

This is simply normal backwards compatibility practice. Keep reading the old 
configurations around forever and don’t change their semantics. If the 
parameter was actually removed then there is no default, and you can just test 
for its presence (maybe this is similar to the change you are proposing?)

> It also doesn't seem different from the discussions about configuration file 
> formats and maintaining the ability to read old formats even after adding the 
> new format.

I specifically asked this about logging.config and no-one cared. This did 
surprise me since I expect that most people do change the logging format.

I agree with you that we can do a better job of making upgrades. Maybe an 
explicit upgrade tool or configuration phase that knows how to convert 
configuration from one release to the next?

J

Reply via email to