Backward Compatibility: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 34: | Line 34: | ||
=== Messages === | === Messages === | ||
* Message ports, whether required | |||
* Format | * Format | ||
* Meaning | * Meaning |
Revision as of 19:53, 26 February 2021
This page is a work in progress
Type of Backward Compatibility
Libraries can typically define backward compatibility with respect to the API and ABI. GNU Radio is a library, but also has a number of other dimensions.
C++ Libraries
- C++ ABI compatibility means that existing binaries that link against GR will dynamically link and run with a new version of GR.
- C++ API compatibility means that a developer's source code (e.g, an OOT module) will build against a new version of GR with no modification.
Python Modules/Libraries
- Pure Python
- C/C++ wrappers (SWIG/PyBind11)
- Embedded Python blocks
GNU Radio Companion
- Schema for block YAML
- Schema for GRC YAML
- Block description (parameters, ...)
- Template code for Python and C++
- Autogenerated code
Data Interfaces
- Serialization (PMT)
- ZMQ (e.g., timeouts)
- Networking (e.g., MTU)
Messages
- Message ports, whether required
- Format
- Meaning
Tags
- When required, when produced
- Format
- Meaning
Text
- Console output
- Logging
Dependencies
- Build environment
- Runtime environment (usually solved by packaging)
Configuration
- Files for GR, GRC
- Environment variables
Behavior
- Algorithm changes
- Runtime changes (e.g., threading behavior)
GNU Radio Versioning
GR uses semantic versioning with four digits (W.X.Y.Z).
- W: general concept, fixed at "3" until a major shift occurs
- X: API version for C++ libraries and Python modules. External C++ and Python code may require modification, sometimes significant.
- Y: ABI version for C++ libraries. External C++ code needs to be rebuilt, but not modified.
- Z: Patch version. No rebuild required.