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> 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 <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> > Cc: Christian Hopps <cho...@chopps.org>; vpp-dev <vpp-dev@lists.fd.io>; > 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> 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 (#15559): https://lists.fd.io/g/vpp-dev/message/15559 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] -=-=-=-=-=-=-=-=-=-=-=-
