"I’ve been around long enough to remember when upward compatibility was something that was expected."
Having been around since before even Unix, I must say I agree totally. As I understand it, Linus does not take kindly to Linux Kernel changes that break forward/upward compatibility (of the ABI). I don't think BIND should do any less. If a new format is needed for more extensive logging, then add a new log option (just as new Kernel interfaces are added from time to time). On Tue, 7 Feb 2017 22:25:36 -0600 Larry Stone <lston...@stonejongleux.com> wrote: > I’ve been around long enough to remember when upward compatability > was something that was expected. A program built to work with the > current version of data (e.g. data records, log records, whatever) or > even a shared library was expected to be able to continue to work > with all future versions without the need for changes or > rebuilding/recompiling. For data, that meant new fields went on the > end of the record so that anything expecting the old format still > found everything where it always was and the new stuff was at the end > of the record where the old programs never even looked. But sadly, > this appears to be a lost art these days. > > Where I work, we have a data set that has 20 years of data in it. > Over the years, the record length was extended but once a field was > placed at a given point in the record, it never, ever moved so that > programs written years ago that had no need for the new fields still > ran just fine. And with hundreds if not thousands of programs around > the company that read this data set, insuring that format changes did > not break things was a very high priority. Occasionally, fields went > away in which case that spot in the record was just left blank for > all new records. > > For the BIND log records described below, what I describe appears to > be what was done through 9.10.0. But then at 9.11.0, we have a field > in the middle of the record being changed (EDNS changed to > EDNS+version). What, IMHO, should have been done here was to put the > version on the end (either going with a split filed - EDNS in one > place and the version in another or by duplicating EDNS by having it > without version where it was and then again with version on the end > of the record) so that old programs parsing the log file still > worked. So instead of: > > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, > > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed, > > EDNS + version, TCP, DO, CD, cookies, local address 9.12.0: client, > > qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, > > cookies, local address, ecs > > > it should have been > > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, > > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed, > > EDNS, TCP, DO, CD, cookies, local address, EDNSversion 9.12.0: > > client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, > > cookies, local address, EDNSversion, ecs > _______________________________________________ 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
