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 (#16380): https://lists.fd.io/g/vpp-dev/message/16380
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]
-=-=-=-=-=-=-=-=-=-=-=-
