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.
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. 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. No matter how hard you make the process, in the end, we can not violate the trust given to us by consumers of VPP by providing them "sometimes" false information. We owe it to the community to do better! [0] https://github.com/FDio/vpp/blob/master/src/tools/vppapigen/vppapigen.py#L1058 [1] https://github.com/FDio/vpp/blob/master/src/tools/vppapigen/vppapigen.py#L1072 [2] https://lists.fd.io/g/vpp-dev/message/16406 [3] https://semver.org/ On Wed, Nov 25, 2020 at 11:51 AM Andrew 👽 Yourtchenko <ayour...@gmail.com> wrote: > A naive implementation of that will break all of the CRC for the affected > messages, which effectively means abandoning the message stability process. > > --a > > On 25 Nov 2020, at 17:27, Paul Vinciguerra <pvi...@vinciconsulting.com> > wrote: > >  > I would like to socialize the idea of removing the backwards_compatible > option from the .api files before the upcoming and any future releases. > > The commit message states: > > This allows adding backwards compatible (as guaranteed by the developer) > enums. > The enums marked backwards compatible are not considered in the CRC > calculation. > > Because it is the widespread practice of the VPP comitter community to > merge commits without Maintainer approval, it is practically not possible > for the developer to assert his/her "guarantee". This is a potentially > risky area. > > If we remove these tags from the .api files before the next release, we > can guarantee a "golden image" of sorts, for lack of a better analogy, of > crc values. > > After the release, backwards_compatible could be used for subsequent > additions, again being removed before the next release is cut. > > Does a repo exist with the code used for verification while "cutting" a > release? > > I don't mind putting up a changeset. > > Paul > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18141): https://lists.fd.io/g/vpp-dev/message/18141 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] -=-=-=-=-=-=-=-=-=-=-=-
