3.0.0

General

• All errors have been renamed, so they conform to Swift Naming Conventions (lowerCamelCase).
• Added Container and ContainerEntry protocols.
• Most methods have their arguments' labels shortened.
• Most documentation have been edited to improve readability.
• Multiple files with results of performance tests replaced with consolidated one.

Containers

TAR

• Added support for TAR containers of various formats.
  Comment: Supported versions include pre-POSIX standard, gnu format as well as pax format with extended headers.

ZIP

• Enabled support for LZMA and BZip2 compression algorithms.
  Comment: If you use SWCompression through Cocoapods then this support is enabled depending on which subspecs are installed. For example, if you have SWCompression/LZMA and SWCompression/ZIP both installed, then containers with files compressed using LZMA will be automatically supported. Other configurations (Carthage or Swift Package Manager) include all parts of framework, so they will have this support enabled by default.
• ZipEntry now conforms to ContainerEntry protocol.
• ZipContainer now conforms to Container protocol.
• Entry's data is now provided through ZipEntry.data() instead of ZipContainer's function.
• Improved detection of directories if container was created on MS-DOS or UNIX-like systems.
• Associated value of ZipError.wrongCRC32 now contains entry's data.
• Fixed a problem where Zip64 sized fields weren't used during processing of Data Descriptor.
• Added some measures to prevent crashes when it is impossible to read text fields (file name or comment) in UTF-8 encoding.
  Comment: This resulted in addition of new ZipError and it was necessary because, apparently, default ZIP encoding is IBM Code Page 437.

Archives

GZip

• Now unarchive function unarchives only first 'member' of archive.
  Comment: Multi-member GZip archives are basically several concatenated archives. Previously, unarchiving such multi-member archive resulted in all data being compounded into one Data object, while in reality these were, probably, separate files. So, it was decided to remain unarchiving of only first member and add a multi-member unarchiving function in the future.
• Added support for archive's options in archive function.
  Comment: This includes original file name, comment, modification time, etc.
• GzipHeader.modificationTime is now Optional.
  Comment: nil value represents situation when no modification time was set in an archive.
• GzipHeader.originalFileName renamed to GzipHeader.fileName.
• Added GzipHeader.isTextFile property which corresponds to a flag in archive's header with the same name.

XZ

• Now unarchive function unarchives only first stream of archive.
  Comment: The reasoning behind this change is the same as for similar GZip change. By the way, this also fixes (technically speaking) a problem of incorrect processing of Stream Padding. If you are worried, the actual fix for padding problem has also been developed.
• Check for archive's footer's 'magic' bytes is now performed at the beginning of processing.
  Comment: According to XZ format specification, archives with wrong footer 'magic' bytes cannot be undamaged or complete. So by performing this check bad archives can be discarded without decoding the entire archive.
• Header's checksum is now checked before parsing reserved flags.
  Comment: Earlier corrupted files could be mistakenly recognized as archives with set reserved flags. This change allows better detection of corruption.

Decompression

• CRC32 check for decompressed data is now performed during BZip2 decompression.
  Comment: If it fails, then error is thrown, and associated value of error contains already decompressed data (similar to other checksums checks).
• Removed internal LZMAOutWindow auxiliary class.

2.4.3

• Fixed incorrect calculation of header's checksum for GZip archives.

2.4.2

• Fixed ZipEntry.fileName property returning file comment instead of file name.

3.0.0 Test 2

The main purpose of this release is to test newly added support for TAR containers. Furthermore, there are a lot of other changes:

• New Container protocol
• Reworked ZipContainer/ZipEntry
• Renamed all errors (so they conform to Swift naming conventions)
• Removed internal LZMAOutWindow class and reworked LZMA code to make it less cumbersome

2.4.1

• Lowered deployment targets' versions for iOS, watchOS, macOS, tvOS (#1, thanks to @agisboye).

3.0.0 Test 1

The main purpose of this test release is to check how switching of availability of different compression methods (BZip2 and LZMA) in ZipContainer works with CocoaPods. Apart from that, there is a couple of other changes:

• BZip2 decompression now checks CRC32.
• GZipHeader.modificationTime is now Optional.

2.4.0

• Added function which creates Zlib archives.
• Reduced memory usage in some cases.
  Comment: Swift 3.1 came with significant improvements to performance of Data operations. This allows to use Data instead of UInt8 array in DataWithPointer. This change should reduce memory usage in some cases (particularly, when parsing ZIP containers).

2.3.0

• Added function which creates GZip archives.
  Comment: In this first implementation created archive is set with default values for most of the fields in the archive's header. These include modification time, flags, OS type, etc. In the future more sophisticated API for specifying these fields will be provided.
• Improved speed of Deflate compression.
  Comment: This was achieved by reimplementing HuffmanTree class (once again).
• Fixed a problem when Deflate uncompressed blocks were created with one extra byte.

2.2.2

Fixed a problem when certainly non-zero uncompressed blocks were instead created with 'length' equal to zero.
Comment: This is related to the fact that Deflate uncompressed block length is limited to 65535 (16-bit integer maximum).

2.2.1

• Now creates uncompressed block instead of compressed with static Huffman encoding if it will provide better results in terms of "compression".
  Comment: This improvement comes with calculations of input data statistics which will be heavily used in decision making when compression with dynamic Huffman code is going to be implemented.
• Small internal changes.
  Comment: These include improvements to code readability in some places as well as negligible speed increase in CRC calculations (CRC tables are now stored as raw arrays of numbers instead of being recalculated every time).