Skip to content

Release 2.0.0 RC1

Pre-release
Pre-release
Compare
Choose a tag to compare
@FrancescAlted FrancescAlted released this 06 May 12:28
· 1040 commits to main since this release
v2.0.0.rc1
5b8fe5a

Changes from 2.0.0-beta.5 to 2.0.0.rc.1

  • [API change] blosc2_decompress_ctx() gets a new srcsize
    parameter to ensure that it does not read past the end
    of the provided buffer. See #144. Thanks to Nathan Moinvaziri
    (@nmoinvaz).

  • [BREAKING CHANGE] The format for frames has changed and
    BLOSC2_VERSION_FRAME_FORMAT is now set to 2. There is no attempt to support
    previous formats, but there will probably be backward compatibility support
    starting from version 2 on.

  • New functionality for updating, inserting and deleting chunks in a super-chunk.

  • Support for special values. Large sequences of repeated values can be represented
    with an efficient, simple and fast run-length representation, without the need to use
    regular codecs.

  • Internal Zstd sources updated to 1.4.9.

  • Internal LZ4 sources updated to 1.9.3.

  • Internal zlib support is provided now by new zlib-ng 2.0.2 (replacing miniz).

  • The support for Snappy codec has been completely removed. Snappy is a C++
    library, which is not good for a library that aims to be fully pure C.
    Snappy was removed from sources in C-Blosc(1) some years ago, so there
    should not be a lot of data compressed with Blosc/Snappy out there (and
    for the existing ones, a transcoding is always possible using C-Blosc(1)).

  • The Lizard codec has been removed. Lizard is a pretty good one, but it
    looks like it is not timely maintained. Zstd/Zlib can cover its place pretty
    nicely.

  • The split of blocks only happens for BLOSCLZ and LZ4 codecs. All
    the rest are not split at all.

  • Public APIs for frames have been removed. Frames should be considered an
    storage detail, so having them accessible publicly should only bring
    unnecessary cognitive load. Care have been carried out so as to ensure
    the same functionality via the super-chunk (schunk) API.

  • [FORMAT] New sparse frame format for on-disk I/O. This allows for storing
    data chunks in super-chunks in separate files inside a directory. The way
    to generate sparse frames is via storage.contiguous=false and
    storage.urlpath=dirname. See README_SFRAME_FORMAT.rst for details.

Assets 2
Loading