On Tue, Nov 13, 2018 at 03:54:11PM +0000, Robert Wilton wrote: > Today, just using the status element alone to mark removed nodes means that > a client would have to check for all changes in the module between two > revisions to determine whether or not the new module revision is backwards > compatible with the old one.
A client needs to know whether it is _affected_ by changes. This requires to match what is used by a client against what has been changed (including any changed deviations). A three digit number simply does not tell you that. <soap> Corner cases: - An implementation claims to support the latest semver but then deviates things back to an earlier version. - An implementation claims to support an earlier semver but then deviates things forward to a more recent version. Of course, nobody would do that... </soap> My point is that semver is _at best_ a hint whether there is a version mismatch potentially affecting a client. It is not sufficient to determine whether there is indeed a problem. In other words, robust automation requires to match what is used by a client against what has been updated (taking deviations into account during the comparison). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
