Feature: Remove Sonatype Lift from Dependency-Update-Tool check

[hayleycd]

Is your feature request related to a problem? Please describe.
Sonatype Lift has been retired, but it still shows up as a dependency update tool option.

Describe the solution you'd like
I don't know if projects that had installed Sonatype Lift are still getting scores that reflect using a tool, but if they are that should probably be changed. A good first step would be to remove Sonatype Lift from the documentation, which currently has a dead link.

I'm not sure if this is better suited for a bug report or a feature request. Apologies if this ended up in the wrong bucket.

[gabibguti]

Hi hayley! Thanks for sharing that info. I'm leaving a +1 here to remove Sonatype both from the documentation and code as a valid Dependency-Update-Tool. I'm in a triager role so let's wait to see what the maintainers and other users think.

[spencerschrock]

Removing from the checks documentation seems like something that can be done immediately.

Removing the code is a use case to consider for structured results and deprecated probes. @laurentsimon what do you think from a probe perspective?

1. Should the code to detect it in rawdata remain, but remove it from our default scoring/policy?
2. Should we also remove the detection code, and have the probe always return outcome negative?
3. Should the rawdata + probe be removed?

Since we haven't released probes yet, it's not like anyone has a policy on it yet. I think 3 works. If probes were released, I think either 1 or 2 could be viable options.

[spencerschrock]

Option 2 could pass along a deprecation notice as well. If we wanted an OutcomeDeprecated or something?

[laurentsimon]

Removing from the checks documentation seems like something that can be done immediately.

Removing the code is a use case to consider for structured results and deprecated probes. @laurentsimon what do you think from a probe perspective?

1. Should the code to detect it in rawdata remain, but remove it from our default scoring/policy?
2. Should we also remove the detection code, and have the probe always return outcome negative?
3. Should the rawdata + probe be removed?

Since we haven't released probes yet, it's not like anyone has a policy on it yet. I think 3 works. If probes were released, I think either 1 or 2 could be viable options.

(3) works for me too.