We released the first external version (0.9.0) of our Rust-based DNP3 library about one year ago. Since then, our customers have deployed the library in production using all our available language bindings.
During this time, there have been zero runtime failures reported in release versions.
I’m proud of this simple fact. It indicates to me that we’ve made sound toolchain and engineering decisions. Our decision to use Rust for our next-gen libraries is paying dividends. The bugs we have encountered have all been simple logic bugs: no memory corruption, thread race conditions, etc. None of them have been fatal errors or otherwise caused user software to fail.
What does 1.0.0 mean?
The Rust community strictly adheres to the semver specification. Prior to 1.0, pretty much anything goes in terms of breaking changes. After 1.0, breaking changes are only allowed when incrementing the major version number.
A 1.0 release is a commitment to API stability. We can continue to add functionality in a non-breaking way, but we can’t break user code until 2.0.
We went through a comprehensive review of the external API for 1.0, and you’ll notice this in the changelog. We’ve incorporated feedback from users and polished the documentation.
Most importantly, we have high confidence in the software. It’s been running in production in client systems for over a year now.
In addition to a stabilized API, this release adds C++ support. The C++ API completely wraps the C API, providing idiomatic C++ resource management (RAII/smart pointers). This is an excellent way to use the library on small-footprint hardware if Rust isn’t an option.
This support involved adding a C++ backend to oo_bindgen which turned out to be no easy feat. It actually lead to a large refactoring of the binding generator. The good news is that we can now support C++ in our Modbus library as well.
Along with our release, we’re announcing an end-of-life date for the OpenDNP3 project:
OpenDNP3 will reach end-of-life on September 1st, 2022.
We previously announced in December 2020 that the project was entering maintenance-only mode. Since then, we’ve been trying to responsibly wind the project down including a recent 3.1.2 release fixing all known bugs.
Instead of letting the project ambiguously slide into an unmaintained state, the following actions will be taken on September 1st:
- The Github repository will be archived, making it read-only.
- The Google Group will be locked, but will remain publicly searchable.
- The project homepage, repository README, and group will be updated to indicate that the project is end-of-life.
We recommend that anyone with production systems using OpenDNP3 dedicate some resources for self-maintenance or make alternative plans.