On Fri, 24 Jul 2020, Kevin A. McGrail wrote:
The intent was to avoid breaking existing production configurations
and third-party tools when feature_block_welcome becomes available, in
order to complete the coverage of backwards compatibility.
I was thinking to publicize the one byte change for the can has feature
to disable it to stay with the old rules. I think that's simpler than
the alias functionality.
Assuming that the only utility of the "alias" directive is backwards
compatibility in this feature, that's obviously a simpler solution. ☺
I haven't been thinking about general utility of "alias" - can anyone
think of a use case that makes it attractive outside backwards
compatibility?
I think it would be better to control feature_block_welcome from the
4.0pre file rather than having to make a code change, regardless of how
small. Is that feasible?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
102 days until the Presidential Election
