On 6/22/20, Neale Ranns (nranns) <nra...@cisco.com> wrote: > Doing only new functionality that the point of introducing the new API is > good because it ensures no-harm-done to all tested functionality of the v1 > API. However, users of the new API will [likely?] use the v2 API for old and > new functions, but they’ll be using it untested for old/existing functions. >
Yes. There is probably some judgement call to be made there. Even if after v2 is introduced, the v1 is rephrased purely in terms of v2, there will be still unique to v2 surface that is from the API itself handler to the actual function that does the work. *probably* doing a couple of spot-check tests could be useful - configure stuff with v1 and check the result with v2, and vice versa. That will also partially take care about the "combinatorics" in part ? I am trying to be very careful in terms of minimizing the amount of new process constraints to be "known good" ones. > This second stage then demonstrates no-harm-done to old functionality via > the v2. From this point on both v1 and v2 should both continue to work, > however, we no longer have test coverage for v1; it could rot. Do we mandate > the v1 must be written in terms of v2 to limit the potential for errors? How > do we continue to guarantee v1 and v2? > Again, probably a judgement call... If all that a change does is add a new field - then rephrasing a v1 in terms of v2 seems a useful approach - it will also trigger some longer-term design thinking "how do I evolve this". But then in some cases it will be impractical or even harmful to dictate the internal implementation. Again, I am trying to be very careful to absolutely minimize the potential red tape... Probably it's worth to document it as "here is what we think might happen, let's collect the experience and revisit it if it is a problem" and then see how it behaves for a couple of releases in practice ? > If foo and bar are related, then can we/do we force users to use v1 or v2 > for both but not a mixture? > We can't force them, not should we. If the the versioned sets are strongly connected, we probably should document the "related API family" in the docstrings, so the users could orient themselves. > I’m interested to know how the arbitration will be resolved. Clients will > likely want all APIs to be classified production whereas maintainers less > so. The current IKEv2 downgrade seems to be rather uneventful. I had sent a unicast mass-mail to anyone who ever touched the API, to initiate their downgrade before the 10th of July. So, barring some exceptions (say if someone was out for a month), I don't expect downgrades to happen. And - to avoid them in the future, we had the idea to enforce with tooling that any new message gets introduced in a "in-progress" state and later has the explicit "productize" step - what do you think ? --a
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16781): https://lists.fd.io/g/vpp-dev/message/16781 Mute This Topic: https://lists.fd.io/mt/74956323/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
