Asdf 3.0.0 is the first major asdf release since 2018.
Thank you to all the contributors!
The following deprecated features are removed in asdf 3.0.0:
Please see the links above or the Deprecations for more details.
As asdf now only supports new-style extensions several new features were added to allow these extensions to retain all the functionality of the now removed type system.
Converters can now defer conversion allowing a different converter to handle serailizing an object. This is useful if a subclass instance can be safely converted to a superclass during serialization. See Deferring to another converter for an example and more information.
Converters have always been “strict” about tag version mismatches (returning ‘raw’ objects if a specific tag version is not supported). This “strictness” now extends to all objects handled by asdf. As all known asdf extensions have already migrated to converters this should pose no issue for users. Please open an issue if you run into any difficulty.
2.15.1 included internally a version of jsonschema. See the jsonschema sub-section of the 2.15.1 section for more details. Asdf 3.0.0 drops jsonschema as a dependency. If your software requires jsonschema be sure to add it to your dependencies.
To accomplish the above improvements to asdf extensions, a major rewrite of
the ASDF block management code was required. During this rewrite
AsdfBlockIndexWarning was added which users will see if they open an ASDF
file with an invalid block index. Re-saving the file (or removing the
optional block index) is often sufficient to fix the file so it no longer
issues the warning when opened.
With the release of asdf 3.0.0 the developers are beginning work on 3.1.0 and 4.0.0. One major change being considered for asdf 4.0.0 is the disabling of memory mapping as the default option when as ASDF file is opened. Memory mapping can offer significant performance gains but also increases the chance for gnarly errors like segfaults and corrupt data. Please let us know if this change would impact your use of asdf in the newly opened asdf discussions
In an attempt to construct a coherent api, asdf 3.1 (and additional minor versions) will likely contain new deprecations in an effort to reorganize and clean up the api. If you are using features that are not currently listed in the User API or Developer API documentation please open an issue. This will help us to know what functions should be preserved, what requires a deprecation prior to removal and which of our un-documented (non-public) features can be removed without a deprecation.
Asdf 2.15.1 includes internally a version of jsonschema 4.17.3. This inclusion was done to deal with incompatible changes in jsonschema 4.18.
Many libraries that use asdf import jsonschema to allow catching of
instances that might be raised during schema validation. Prior to asdf 2.15 this
error type was not part of the public asdf API. For 2.15 and later users are
expected to import
asdf.exceptions (instead of jsonschema
To further ease the transition, asdf will, when possible, use exceptions imported
from any installed version of jsonschema. This means that when the asdf internal
jsonschema raises a
ValidationError on a system where jsonschema was separately
installed, the internal jsonschema will attempt to use
ValidationError from the
installed version. This should allow code that catches exceptions imported from
jsonschema to continue to work with no changes. However, asdf cannot guarantee
compatibility with future installed jsonschema versions and users are encouraged
to update their code to import
Finally, asdf is temporarily keeping jsonschema as a dependency as many libraries expected this to be installed by asdf. We expect to drop this requirement soon (likely in 3.0.0) and this change might occur in a minor or even patch version.