e...@thyrsus.com said: > If you mean changes to Mode 6, I'm not sure enough that shipping both hex > and text would fix anything to we want to do it. How do we know old code > wouldn't barf on the following text? Naive implementations in scripting > languages would do that.
If you look at the old code up a level from the detailed chunk that sends each field, you find that there is logic to scramble the order and send bogus extra fields. The intention was to make sure client code didn't do the simple things that would break when fields are added. So I think that old code will keep working as long as we keep sending the old fields without changing them. Or at least any somewhat sane code. I don't think we have to worry about the rest. e...@thyrsus.com said: >> Do we need to start tracking what we will support and/or develop >> a policy for when we drop support for a slot? > I've been obsessive about documenting visible changes; see docs/ntpsec.txt > for them all. There have not been many such things, and only one change in > Mode 6. There's one context in which it ships a driver name rather than a > number now. What I was trying to suggest was a list of the fields and which ones came from ntp classic (call it version 0.0) and which ones we added and which version we added them in and which fields they replace and/or have been replaced by and/or some policy about how long we support each version. I'm assuming that we can add things to test them without a lot of discussion, but maybe we should think twice before we ship an actual released version that has them since that commits us to support for a long time. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
