> On 25 Feb 2020, at 21:11, Christian Hopps <cho...@chopps.org> wrote: > > > >> 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."?
More or less. IFF one really wants the new api in 1908. Since the aim is to keep it “stable”. > > 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 :) Right, so I think for any given user X it translates to “I want to use stable plus my features”. When we iterate X over the set of users, the target branch result becomes master really, doesn’t it ? :) > > 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. That’s the APIs in the master prior to the API freeze, in my book. The today’s situation is: - want bleeding edge features ? Use master. - want sort-of-boring-stability ? Use release branch Now, I am really interested why the folks who do want to experiment with the APIs, do not pick the master ? (Say, specifically for your case). —a > > 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 (#15528): https://lists.fd.io/g/vpp-dev/message/15528 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] -=-=-=-=-=-=-=-=-=-=-=-
