Skip to content

Releases: clearlydefined/service

v2.0.1

30 Oct 23:42
@elrayle elrayle
v2.0.1
007f4e7
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
v2.0.1 Latest
Latest

What's Changed

Bug Fix

  • set version to v2.0.1 in prep for bug release including deploy with operations v3.1.2 by @elrayle in #1219

Full Changelog: v2.0.0...v2.0.1

Contributors

elrayle
Assets 2
Loading

v2.0.0

28 Oct 16:39
@elrayle elrayle
v2.0.0
4bf121b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
v2.0.0

Release tag: v2.0.0

Upgrade Notes

No steps are required to upgrade to this release as a user of ClearlyDefined. There are no changes to the API.

The change of most interest is the addition of support for scancode LicenseRefs and the update to scancode v32.1.0.

All major changes are related to changes in newly created definitions based on changes in the crawler data output by license tool updates and license extraction process.

Note: Requests for definitions will result in a recomputation of the definition to include the changes described in this release. Definition requests do not initiate a harvest request when a definition already exists. In that case, the caller must make a harvest request through the service API in order to update raw tool results from which the definition will be constructed. Note as well that harvesting takes significant time. There will be a delay from the time the harvest request is made before the results will be reflected in a definition request.

What’s changed

Major Changes

Forces definitions with older schema to be recalculated the next time they are requested. This is required for the data changes including the addition of support for scancode LicenseRefs.

Support scancode v32.1.0 and non-SPDX licenses using LicenseRef

ScanCode major versions 31 and 32 introduced pretty drastic changes to its output format which required significant changes to our summarizing logic. Multiple PRs brought in the support for LicenseRefs identified by ScanCode.

What this means for you?

When a license is identified as NOASSERTION or OTHER, it is possible that ScanCode can identify the license as something other than one of the SPDX licenses. Several possibilities each with a different solution...

  1. ScanCode has already identified a non-SPDX license - In this case, simply requesting the definition will initiate a recompute of the definition which will replace the current license with the ScanCode LicenseRef
  2. ScanCode has not identified a non-SPDX license with the previous version os ScanCode - In this case, a /harvest request is required to get ScanCode to run again. Ultimately, once harvesting is completed, the definition will be re-generated. If a new LicenseRef was identified, it will be part of the re-computed definition.
  3. ScanCode cannot identify a license - You won't know this in advance meaning the step to take is to send a /harvest request. The result of the re-computed definition will be the license is unchanged. Sending additional /harvest and /definitions requests will not change the results or the definition.

PRs for LicenseRef support

  • Add new summarizer for recent ScanCode versions (e.g. v32.1.0) by @lumaxis in #1056
  • Update to SPDX v0.1.9 to support LicenseRef mapping in scanner and parser by @qtomlinson in #1205
  • Update license normalization process to support LicenseRef by @lumaxis in #1148
  • maintain precedence when joining Scancode license expressions by @lumaxis in #1087

When joining license expressions with AND: 'MIT OR Apache-2.0', 'GPL', precedence should be preserved in the result. The joined expression was incorrectly constructed as GPL AND MIT OR Apache-2.0. It is now correctly constructed with precedence as GPL AND (MIT OR Apache-2.0).

Additional data related changes

  • Update to SPDX v0.1.8 to avoid adding unnecessary brackets in stringify by @qtomlinson in #1203

This update brings in SPDX PR clearlydefined/spdx#30

The expressions "LGPL-2.1-only OR MIT OR BSD-3-Clause" and "LGPL-2.1-only OR BSD-3-Clause AND MIT" are valid and simplified forms of SPDX expressions. Refer to the SPDX specification for more information (https://spdx.github.io/spdx-spec/v2-draft/SPDX-license-expressions/#d4-composite-license-expressions)

Minor Changes

  • Update license mapping with latest ScanCode LicenseDB data by @github-actions) in #1137, #1200

Bug Fixes and Patches

Development related

  • Add source location in definitions for sourcearchive packages by @qtomlinson in #1108
  • Fixed origins api for pypi components throwing 500 error when invalid group id is provided by @yashkohli88 in #1172
  • Fixed origins api for maven components throwing 500 error when invalid group id is provided by @yashkohli88 in #1176)

DevOps

Dependencies

Full Changelog: v1.3.1...v2.0.0

Contributors

lumaxis, elrayle, and 6 other contributors
Assets 2
Loading

v1.3.1

16 May 04:11
@elrayle elrayle
v1.3.1
ce3383e
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.3.1

Patch release to update prod deploy workflow to use [email protected]. See operations v1.1.0 release notes for more information.

Changes: v1.3.0...v1.3.1

Assets 2
Loading

v1.3.0

16 May 03:05
@elrayle elrayle
v1.3.0
f1a19e2
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.3.0

Release Highlights

Release tag: v1.3.0

There is one change of interest:

  • Conda was added as a package manager source. Details on usage are provided below under the Add Conda support section.

Upgrade Notes

No Action Required. Optionally, you can start requesting harvests for Conda packages. See details below.

What’s changed

Changes: v1.2.0...v1.3.0

Minor Changes

Add Conda support

There is one significant change in this release to add support for Conda package manager. It is classified as minor because it is additive. It does not impact the functioning of previously supported package managers.

Coordinates syntax:

  • type (required) - identifies to use the Conda provider (values: conda | condasource)
  • provider (required) - channel on which the package will be crawled. (values: conda-forge | anaconda-main | anaconda-r)
  • namespace (optional) - architecture and OS of the package to be crawled (e.g. win64, linux-aarch64). If no architecture is specified, any architecture is chosen.
  • package name (required): name of the package
  • revision (optional): package version and optional build version (format: (${version} | )-(${buildversion} | )) (e.g. 0.3.0, 0.3.0-py36hffe2fc). If it is a conda coordinate type, the build version of the package is usually a conda-specific representation of the build tools and environment configuration, and build iteration of the package (e.g. for a Python 3.9 environment, buildversion is py39H443E). If none is specified, the latest one will be selected using the package's timestamp.

Examples:

  • conda/conda-forge/linux-aarch64/numpy/1.13.0
  • condasource/conda-forge/linux-aarch64/numpy/1.13.0
  • conda/conda-forge/-/numpy/1.13.0/
  • conda/conda-forge/linux-aarch64/numpy/-py36

You can find additional information in the crawler v1.1.0 release notes.

Bug Fixes and Patches

Development related

DevOps

Dependencies

Contributors

lumaxis, elrayle, and 3 other contributors
Assets 2
Loading

v1.2.0

05 Apr 12:27
@elrayle elrayle
v1.2.0
ea4a577
Compare
Choose a tag to compare
v1.2.0

Release Highlights

Release tag: v1.2.0

There are two changes of interest:

  • improved coordinate checking for PyPI
  • addition of an action that automatically updates the LicenseDB data

The remaining changes impact the development and deploy processes.

Upgrade Notes

There are no required actions for this upgrade.

What’s changed

Changes: v1.1.0...v1.2.0

Minor Changes

Improve coordinate checking for PyPI

Action to automatically update the LicenseDB data

Display information related to the deploy in the default endpoint

The sha of the deployed code is displayed at the default endpoint. This is useful for debugging.

Example:

{ "status": "OK", "sha": "89555eb2a172d4c804d1f4541377e300de77ca63" }
  • get latest release version from GitHub API for prod deploy (#1055) (@elrayle)
  • get version from package.json instead of release (#1053) (@elrayle)

Bug Fixes and Patches

Development related

Move deploy process to GitHub Actions

Dependency updates

Contributors

lumaxis, elrayle, and 2 other contributors
Assets 2
Loading

v1.1.0

13 Feb 19:27
@elrayle elrayle
v1.1.0
3e1ed97
Compare
Choose a tag to compare
v1.1.0

Release v1.1.0 is a minor release.

Release Highlights

  • updates to Mongo indexing
  • deprecate TRIMMED_DEFINITION_MONGO_COLLECTION_NAME

Upgrade Notes

There are no required changes to move to this version. There is a recommended change related to a deprecation. See Deprecations section for more information.

updates to Mongo indexing

API affected: get definitions with sort fields set to descending.

For example:

https://api.clearlydefined.io/definitions?type=composer&provider=packagist&namespace=10up&name=wpsnapshots&sort=namespace&sortDesc=true

Sorting order is determined by:
sortDesc=false – sort ascending (default)
sortDesc=true – sort descending

Behavior in v1.0.0

In this version, the sort honored sortDesc for any field identified as a sort field. Within multiple matches of those sort fields that share the same value, the results were being sorted ascending by coordinates regardless of the value of sortDesc. This is incorrect behavior.

New Behavior in v1.1.0

The new behavior sorts the identified sort fields and the coordinates in the same direction as identified by the sortDesc parameter.

It is recommended, but not required, that you delete the indices that are NOT documented in the _createIndexes method in clearlydefined/docker_dev_env_experiment/service/providers/stores/abstractMongoDefinitionStore.js

If you accidentally delete too many indices, they will be regenerated the next time you restart the service. NOTE: This can take a long time.

Deprecations

Deprecating TRIMMED_DEFINITION_MONGO_COLLECTION_NAME. If you are using this configuration, you should update the configs to use the name DEFINITION_MONGO_TRIMMED_COLLECTION_NAME instead.

What’s Changed

v1.0.0…v1.1.0

Bug Fixes and Patches

Documentation

Contributors

JamieMagee, elrayle, and qtomlinson
Assets 2
Loading

v1.0.0

01 Feb 19:13
@elrayle elrayle
v1.0.0
5614efb
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v1.0.0

Release v1.0.0 is a re-release of the current production service which was last released Feb 28, 2023. The purpose of this release is to establish a known baseline as the starting point for the transition to using Semantic Versioning for the released versions. Future releases will have a Docker image stored in GitHub Packages.

Release Highlights

Release tag: v1.0.0

NOTE: The version in package.json differs from the release tag because it was previously set and could not be changed.

Breaking Changes

none

Upgrade Notes

No Action Required

What’s changed

This release is identical to the code that has been the production release since Feb 28, 2023.

previous-release:

Changes: previous-release...v1.0.0

Assets 2
Loading