API stability is borderline critical for a project like VPP I think. Yes, it can be used stand-alone, but real value is added by building products on top of it.
Also important is having an API framework that allows for backward-compatible changes to the API for making improvements. I'm not sure if VPP has the latter, but if there's too much pain with your proposed rules I think the latter should addressed rather than sacrificing the former. So I support your rules. Thanks, Chris. > On May 14, 2020, at 8:28 AM, Ole Troan <otr...@employees.org> wrote: > > Andrew and I have discussed a process around API changes with the goal to > limit the impact on VPP consumers. > One big painpoint in tracking VPP releases for users of the VPP binary has > been API changes. > > We want to ensure: > - A production API never changes. > > - A production API can be deprecated with one release notice. > E.g. show_version_2 is introduced in 20.01 and show_version_1 is marked as > deprecated. > show_version_1 is marked with "option delete_by = "v20.05"; > > - APIs marked as experimental / not released can change with no notice. > Added support for option status = "in_progress"; > > This patch: > https://gerrit.fd.io/r/c/vpp/+/26881 > > has a tool "crcchecker" that we intend to run as part of the verify job. > It will block modifications to existing production APIs. > make checkstyle-api > It also supports dumping API manifests and make API comparisions across > releases/revisions/commits. > > A production API is defined by having .api semantic major version > 0. > New messages can override that by setting status="in_progress". > > The consequence of this is that developers must maintain two (or more) > versions of an API for some time. > This is obviously painful, but at least it aligns cost and benefit better > than when we forced the API users to do it. > > Looking back from 17.01 onwards, it looks like we on average have done about > 50 backwards incompatible changes per release. > That's ignoring the work on API typing, which have resulted in significantly > more changes. > > The hope is that we can start v20.09 development with this process in place. > > What do people think? > > Best regards, > Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16381): https://lists.fd.io/g/vpp-dev/message/16381 Mute This Topic: https://lists.fd.io/mt/74203477/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
