Backwards-compatibility and deprecation policy¶
Since Soledad has not reached a stable 1.0 release yet, no guarantees are made about the stability of its API or the backwards-compatibility of any given version.
Currently, the internal storage representation is experimenting changes that will take some time to mature and settle up. For the moment, no given SOLEDAD release is offering any backwards-compatibility guarantees.
Although serious efforts are being made to ensure no data is corrupted or lost while upgrading soledad versions, it’s not advised to use SOLEDAD for any critical storage at the moment, or to upgrade versions without any external data backup (for instance, an email application that uses SOLEDAD should allow to export mail data or PGP keys in a convertible format before upgrading).
The points above standing, the development team behind SOLEDAD will strive to provide clear migration paths between any two given, consecutive minor releases, in an automated form wherever possible.
This means, for example, that a migration script will be provided with the
0.10 release, to migrate data stored by any of the
versions. Another script will be provided to migrate from
etc (but not, for instance, from
At the same time, there’s a backwards-compatibility policy of deprecating APIs
after 2 minor releases. This means that a feature will start to be marked as
0.10, with a warning being raised for 2 minor releases, and
the API will disappear completely no sooner than in