You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Description
@swift-nav/devinfra
Follow through on legacy API deprecation plan as previously agreed upon.
The goals of this PR are:
- Keep the legacy API in place but make it much more difficult to access
- Any usage of the legacy API must be explicit on behalf of the user
- Legacy API no longer implicitly available by including `libsbp/sbp.h`
- legacy headers must be explicitly included
- All header files in the legacy API generate a compile time message at
the point of inclusion warning that they will be removed in version 6
- All symbols in the legacy API are marked with the `deprecated`
attribute
- All mentions of `v4` (ie, the modern replacement API) removed from
headers, source files, etc. Moving forwards there will be no such thing
as the "v4" API, there will just be the libsbp API
- Shuffle files around in the source and include directories to better
reflect the transition from legacy to modern APIs
- The correct way to include a package worth of message types is by
including (eg) `libsbp/observation.h`
- v4 "package" header files (eg `libsbp/v4/observation.h`) are still
available but are deprecated. They generate a compile time message
warning that they will be removed in version 6 and then include
`libsbp/<package>.h` (the new header file) automatically
- The end goal of all of this is that there is the libsbp API
(previously know as the v4 API), plus a legacy API which is hanging
around but very much a second class citizen.
- The legacy code is sufficiently separated so that removing it in
version 6 should be a fairly trivial task consisting mostly of deleting
some source/header files and templates
# API compatibility
Does this change introduce a API compatibility risk?
Nothing significant. The vast majority of symbols are present and have
the same meaning as before. Users of the legacy API may find that they
need to alter some include directives, but the warnings should be
obnoxious enough that they have no excuse for not transitioning to the
modern API immediately.
The one piece which has changed is the C++ state wrapper (`sbp::State`)
which previously was capable of handling both the legacy and modern
APIs. This has been broken up so that `sbp::State` now only handles the
modern API, and a new class `sbp::LegacyState` inherits from
`sbp::State` and adds a coupld of functions to deal with the legacy API.
This class is immediately deprecated and marked for deletion in version
6
The modern API is untouched by this PR
## API compatibility plan
If the above is "Yes", please detail the compatibility (or migration)
plan:
All users must transition to the modern API immediately if they haven't
already done so.
# JIRA Reference
https://swift-nav.atlassian.net/browse/AP-643
0 commit comments