> On Feb 25, 2020, at 12:48 PM, Andrew Yourtchenko <ayour...@gmail.com> wrote: > > 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.
So I think I'm reading that as: "It's fine to add the new API message (e.g., ip_route_lookup); however, since the new API would be immediately frozen in the release (and thus not be able to be changed again on that release/branch), you'd like it to have soak time on master prior to it being brought into a release."? I wonder what the soak time would be though, as it's a new API it might take quite some time for people to use it. A lot of the people that use the binary APIs might also only use release branches (e.g., our use) so it might only be exercised once it gets into the next release, and then it's the same situation as we started with (new API being tried out on release branch :) It'd be nice to have a way to label an API added post release as "experimental" or something so that it could get more exposure with the expectation that that exposure might cause the API to change. Thanks, Chris. > 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> 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 <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> >> Cc: Christian Hopps <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 (#15527): https://lists.fd.io/g/vpp-dev/message/15527 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] -=-=-=-=-=-=-=-=-=-=-=-
