I have to say this is an odd argument. Anyone that does real world code in enterprise environments knows that you have to migrate between versions. Config value that are renamed have to allow for time migrate to a new value. Hard switches will upset customers very quickly. They need time to be warned to move. Any quality configuration systems has a notion of is the value defined, is there some sort of fall back mapping, and maybe a defined default ( as in the case of ATS) that is used if there is no value defined and no fall back mapping of a deprecated setting. Values take time to be removed. They happen at the start of a Major version release, never on a B or C version level change. They need at least on Major (A version) to be deprecated before they can be removed. I think the only exception to this is that a value was added as experimental and was never made official/stable. ( ie nobody should be using it in production) just my quick 2 cents
Jason On Tuesday, November 22, 2016, 11:13:42 AM CST, James Peach <jpe...@apache.org> wrote: > 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
