Skip to content

Releases: snyk/rpm-parser

v3.1.1

10 Apr 12:54
297bbfb
Compare
Choose a tag to compare

3.1.1 (2024-04-10)

Bug Fixes

  • upgrade node and dependencies version UNIFY-75 (276e8b3)

v3.1.0

23 Feb 08:59
0292ed6
Compare
Choose a tag to compare

3.1.0 (2023-02-23)

Features

  • add support for modules (1f3ccee)

v3.0.0

13 Dec 16:03
82ce88a
Compare
Choose a tag to compare

3.0.0 (2022-12-13)

Code Refactoring

BREAKING CHANGES

  • changes the returned type from the extracting function
    getPackages. So far a string has been returned, which delimited each
    entry in the DB with a newline, and each part of the entry with a tab.
    Instead, we now pass a proper type back to the caller, making it easier
    to have (and parse) optional fields.

v2.3.2

09 Aug 09:56
b3f6bc1
Compare
Choose a tag to compare

2.3.2 (2022-08-09)

Bug Fixes

  • extract version formatting to a new func (6101d33)

v2.3.1

07 Jun 14:14
ac0999c
Compare
Choose a tag to compare

2.3.1 (2022-06-07)

Bug Fixes

  • use sql.js instead of sqlite lib (4e63216)

v2.3.0

01 Jun 13:02
d67cc10
Compare
Choose a tag to compare

2.3.0 (2022-06-01)

Features

  • support rpm>=4.16 using sqlite instead of berkeley DB (7c11592)

v2.2.1

27 Oct 15:38
ee13dc9
Compare
Choose a tag to compare

2.2.1 (2020-10-27)

Bug Fixes

  • exclude blobs with private RPM tags when reading dependencies (ae0ecfe)

v2.2.0

15 Oct 11:12
7fe13dd
Compare
Choose a tag to compare

2.2.0 (2020-10-15)

Features

  • revert throwing on encountering errors (7527ff3)

v2.1.0

15 Oct 08:34
f7a8cde
Compare
Choose a tag to compare
v2.1.0 Pre-release
Pre-release

2.1.0 (2020-10-15)

Features

  • return a list of RPM packages for easier processing (89482a5)

v2.0.0

08 Jun 11:42
c9d36e5
Compare
Choose a tag to compare

2.0.0 (2020-06-08)

Features

  • target node 8, better code generation (4bc8f40)
  • upgrade event-loop-spinner, reducing waits (1b07555)

BREAKING CHANGES

  • will no longer work on node 6

This was already set in the engines field, and in
.nvmrc, and CI, so is probably not too controversial.

As we have performance sensitive code which is async,
it's probably (untested) better to let the compiler
take advantage of the platform we actually support.