> On 25 Feb 2020, at 22:09, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Feb 25, 2020, at 3:44 PM, Andrew 👽 Yourtchenko <ayour...@gmail.com> wrote: >> >> 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). > > FWIW, I'm absolutely fine following whatever guidelines, it's open source and > I'm sure people can make things work with whatever is best for both > project[s].
Exactly, that’s why I love this discussion and hope other folks might eventually comment as well with their arguments. And thank you for bringing this up. I did discuss with a few folks whether things like an “official“ version of http://trailing.myvpp.net/ might be of use, etc. - so having more real-world feedback is extremely helpful, thanks a lot! My ultimate dream is that there is no branches whatsoever, and the “release” is simply a moment when we fork off an API translation layer that freezes the API view for the current version, combined with the trailing branches for more commit predictability... what do you think ? > > In my case we're not really talking about an API that is "bleeding edge", but > rather "waited around for someone to need/implement it". Doing a route/fib > entry lookup isn't very bleeding edge given what VPP does. :) Sure, but it is a new functionality. Which needs testing/feedback by the community, right ? That to me *at present* is a criteria for master. The idea that I am working on is essentially an “api freeze” which creates a separate endpoint with translation layer into the current master - this way one can have the stable api *and* potentially experiment by leaking some of the messages through. We need this capability in general - not just stable branch - to be able to “freeze” some of the messages and at the same time keep the others “liquid”, and some old ones as “to be deprecated in release XX.YY” Now that I think of it, it might be a question of individual message markup within the .api files - it would be seemingly a much simpler solution, but then we are bound to have _v2, _v3, ... messages, and individual developers need to deal with their deprecation... And ensure that the messages crc gets tracked.... so the total volume of complexity is the same, it’s just more thinly spread ? :-) > > My use case is interfacing an external IKE daemon (strongswan), I want to do > a route lookup (rather than download the entire FIB content and search for a > match myself hoping to use the same criteria that VPP would, which is the > only current API solution available). Makes sense. > > I'd like to contribute my strongswan changes back to strongswan project, but > having them only be usable for some future yet-to-be-released version of VPP > might not be useful to people shipping products based mostly on > "sort-of-boring-but-stable" features. let’s extrapolate. Let’s imagine we integrate it into stable/1908. Now also feature B and feature C owner/user rightfully wants to do the same (And given the above assumption I won’t gate that request), so at which point this becomes a simply diverged master ? And what is the reason of even having the stable/1908 branch then ? > Also worth noting, I implemented a basic route lookup (prefix based, from a > given table, either exact or longest prefix match), I didn't add any other > filtering or fanciness. I figured fanciness could be added later (if needed), > and went for simple, and if more complexity was needed, well there's always > what came before it. :) Sure, simple is good. If the maintainer of the component is happy to add it to stable/1908 - I am happy to do it as well (with the outlined caveats :) Alternatively an option is to leave a change uncommitted and periodically rebase it (this way you as the author get more control and the status is clear, rather than users dealing with the API updates) But then, it is best first committed to master, then backported (or then double-committed to stable). (There probably is no doubt that we at all costs don’t want to end up with stable branch having features that are not in master?) —a > > define ip_route_lookup > { > u32 client_index; > u32 context; > u32 table_id; > u8 exact; > vl_api_prefix_t prefix; > }; > define ip_route_lookup_reply > { > u32 context; > i32 retval; > vl_api_ip_route_t route; > }; > > Thanks, > Chris.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15531): https://lists.fd.io/g/vpp-dev/message/15531 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] -=-=-=-=-=-=-=-=-=-=-=-
