Hi Paul, > No. > > crc is actually a misnomer here. If you say crc, one assumes binascii.crc32. > That is not what crc is. What is exposed as .crc is actually a custom > function in vppapigen called foldup_blocks, which is dependent on the version > of vppapigen that generated it.[0]. (Ask me how I know...) In fact, in the > source is a fixup_crc_dict [1] with pre/post 6/25/20 crc's hardcoded.
the crc is a crc of the string representation of an API message including all its dependent types. > backward_compatable is a misnomer. If you marked existing fields as > backward_compatable, which is true by common definition of the option's name, > that value is removed from the crc and everything trusting the crc breaks. > > Having the same crc match against different sources is a real problem. It is > a violation of a consumer's trust. there is a bit of history here. prior to more explicit types a flags field would be represented as "u32 flags;". defining flags as an enum with explicit values makes the API more explicit, but also limits how easy it is to evolve. the backwards compatible option for enums try to strike a balance between those two. it does of course depend on the developers doing the right thing. it would indeed make sense to time-limit the backwards_compatible option, otherwise as you say users cannot depend on the new messages tagged as such. with the current process that would likely require a _2 of the message. > History has already shown that you have made the process overly difficult. > Let's go back and revisit [2]. We have a version (a semver) attached to the > .api. The refusal in [2] was to continue to follow the rules of semantic > versioning in the name of expediency. (For those who are having trouble > following along, if a bug is fixed, the version is to be incremented[3]. In > this case, it was decided to not increment the semver, to not trigger the > overly painful process) A single semver with differing results violates our > contract with the consumer. are you arguing that you would have a semver and only a semver? the current scheme is automatic with no dependency of the developer having to bump the semantic version. it also has the granularity of the per-message level, allowing the user of the API to specify a manifest of the messages with versions (aka crcs) of the messages used. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18146): https://lists.fd.io/g/vpp-dev/message/18146 Mute This Topic: https://lists.fd.io/mt/78503177/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
