I think putting it in 4.0 pre makes a lot of sense. I will look at how to do that.
On Fri, Jul 24, 2020, 17:06 John Hardin <[email protected]> wrote: > 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
