> Adding a new API into an existing file will still change the CRC on the > plugin/module
Looking into a .api.json file, I see "crc" only for messages, but the whole file also ends with a "vl_api_version" value. > if we are aiming for binary compatibility Crc values guard against backward-incompatible edits. Vl_api_version changes even for backward compatible edits (within the same .api file), so perhaps we can tolerate such change. Vratko. From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Andrew Yourtchenko Sent: Wednesday, February 26, 2020 6:19 PM To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? Hmm so that’s an interesting question. Adding a new API into an existing file will still change the CRC on the plugin/module - which means that if we are aiming for binary compatibility (which is I think what we are doing) - it means we can only allow the one-shot addition of new .api files, right ? --a On 26 Feb 2020, at 17:26, Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <vrpo...@cisco.com<mailto:vrpo...@cisco.com>> wrote: > as soon as the CRC of any existing messages does not change, a patch is okay > to include into 19.08 Does that mean we want an api-crc job also for 1908 stream? We currently have api-crc job only for master, because other branches were not expected to edit .api files. Vratko. From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew Yourtchenko Sent: Tuesday, February 25, 2020 6:49 PM To: Dave Barach (dbarach) <dbar...@cisco.com<mailto:dbar...@cisco.com>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? With my 19.08 release manager hat on, For the current state of the matters my view is “as soon as the CRC of any existing messages does not change, a patch is okay to include into 19.08”. This applies recursively, meaning that if one add a new message to 1908, it comes in as “frozen” with no further changes. Why ? Because if it is not perfect API wise it’s not stable, it should first settle down on master. That’s the logic I had been using so far. I am currently working on an 19.08 api translation layer experiment that in principle should allow more freedom... but till that is successful that is my point of view. Unless the community decides otherwise, of course. --a On 25 Feb 2020, at 16:56, Dave Barach via Lists.Fd.Io <dbarach=cisco....@lists.fd.io<mailto:dbarach=cisco....@lists.fd.io>> wrote: Dear Chris, Adding missing flags to ipsec_sad_flags shouldn’t break much of anything. Never say never, but for me, I wouldn’t hesitate to merge such a patch. Adding an entirely new message will renumber subsequent core engine messages, and implies client recompilation. My $0.02: again, not such a big deal. What do other people think? Dave P.S. in master/latest, enum ipsec_sad_flags has moved to .../src/vnet/ipsec/ipsec_types.api... From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> On Behalf Of Christian Hopps Sent: Tuesday, February 25, 2020 10:25 AM To: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>> Subject: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? I've got a couple of changes to the ipsec API that I'd like to upstream to match the vpp "kernel" code I'm going try and upstream to strongswan. 1) Add: Add an ip_route_lookup/reply pair (semver minor++) 2) Fix: Add IS_INBOUND flag (value 0x40) to ipsec_sad_flags (semver patch++) optional) Fix: possibly add the other missing flags to ipsec_sad_flags so they can be properly returned on queries. I think submitting these for release branches is OK after reading https://wiki.fd.io/view/VPP/API_Versioning I'm coding to 19.08 right now, if I'd like to have those changes in that branch I would imagine I'd need to also submit changes for 20.01 and master? I admit to being confused about the CRC stuff, and the warnings in the 19.08.1 release notes and what those warnings imply. Is it safe to assume the CRC stuff can be ignored and external clients will still work (given no semver major change) even if a CRC chagnes? Side Note: from the API link: "If a new message type is added, the old message type must be maintained for at least one release. The change must be included in the release notes, and it would be helpful if the message could be tagged as deprecated in the API language and a logging message given to the user." Given there are 3 releases per year, only maintaining an old compatible function for 1 release seems rather aggressive. It does say "at least" though. :) Thanks, Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15586): https://lists.fd.io/g/vpp-dev/message/15586 Mute This Topic: https://lists.fd.io/mt/71535081/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
