> On 13 Jun 2019, at 17:55, Barry Margolin <bar...@alum.mit.edu> wrote: > > In article <mailman.716.1560422804.711.bind-us...@lists.isc.org>, > Matthijs Mekking <matth...@isc.org> wrote: > >> ## Deprecating >> >> A configuration option that is candidate for removal will be deprecated >> first. During this phase the option will still work, but we will be >> communicating to users that the option is going to be removed soon. A >> user that has deprecated options configured will see warnings in their >> logs and needs to take action to get rid of those log messages. >> Configuration options that are deprecated will be identified in the >> Release Note for the release they are deprecated in. > > As others have said, I'm not sure how effective this will be. I suspect > most people don't check the logs routinely, only when something goes > wrong.
The policy isn’t intended to take care of people who don’t really care. The policy is here to have a transparent and careful way how to remove options. > Is it really much of a hassle to leave the obsolete options in the > parser, but just ignore them? Unfortunately, yes, it adds to overall entropy of the source code, and we aim to fix the cruft that has accumulated in last 20 years. This is more of high level design decision, but it is something that has to be done because it is connected with maintenance burden. And it’s a burden we don’t have to really carry on our shoulders. Ondrej -- Ondřej Surý ond...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users