Deprecate older versions of scancode

[elrayle]

Description

ClearlyDefined supports multiple versions of scancode-toolkit. Many of the versions use a different data format requiring special processing. The code would be cleaner if fewer versions were supported. However, removing versions requires data in the older format to be reharvested.

This issue proposes deprecating and later removing support for older versions of ScanCode.

Deprecation vs. Removal: Typically when removing functionality, it is deprecated in the current major release and removed in the next major release. This is consistent with the requirements of semantic versioning.

Considerations:

• When support for a version is added, existing data generated by older versions remain unchanged. As such, processing of the format for the older version needs to continue.
• Removing support for a version requires re-harvesting of dependencies with data in the older format. Need an estimate of the number of dependencies that would be impacted if versions were removed.

Questions:

• How long should a version be supported?
• How much processing will be required to reharvest?

Scancode Versions

Supported now

version	release date	processing approach	supported?
< 2.2.1			--
2.2.1	2017-10-05	2.2.1 processing	YES
2.9.1	2018-03-22	2.9.1 processing	YES
2.9.2	2018-05-08	2.9.2 processing	YES
2.9.8	2018-12-12	same as 2.9.2 processing	YES
3.0.0	2019-02-14	3.0.0 processing	YES
3.0.2	2019-02-15	same as 3.0.0 processing	YES
30.1.0	2021-09-25	30.1.0 processing	YES
32.0.8	2023-10-16	This will require different processing.	in progress

NOTES: Versions not on this list indicates that version was never used by ClearlyDefined. As such, there are no curations in the format specific to one of those versions. And no processing was put in place for those versions.

[lumaxis]

• Removing support for a version requires re-harvesting of dependencies with data in the older format. Need an estimate of the number of dependencies that would be impacted if versions were removed.

That only applies for dependencies that have not yet been harvested by a newer version already anyway, right? With some of these very large time gaps, I'd expect that to have already happened for most dependencies anyway? 🤔

I'm not sure if we want to commit to a fixed timeframe going forward but looking back, I definitely would feel comfortable removing support for versions <3.0.2 with them being more than 5 years old at this point.