Proposal: Remove the allowDynamicVersions configuration option

[sschuberth]

The analyzer's allowDynamicVersions option currently defaults to false, which can be a burned for users whose projects don't follow the practice of having lockfiles. To ease the onboarding of such users, I'd like to propose to remove the option completely and allow the analysis of all projects by default, in favor of adding e.g. a hasLockedDependencies property as part of the Project class that just documents whether version of dependencies may dynamically change or not.

What do @oss-review-toolkit/core-devs think?

[tsteenbe]

Changing the allowDynamicVersions option has been on the back of my mind for a while - this should be "best practice" policy rule choice for ORT admins and not something ORT enforces by default. As ORT maintainers we have not been the best at ensuring ORT results files from older versions of ORT can still be read in by the lastest version - this has resulted in lots of frustration with several ORT users so not fan of implementing the removal of allowDynamicVersions as breaking change.

Alternative proposals:
A) Remove allowDynamicVersions Analyzer option but don't fail ORT results if present and add hasLockedDependencies property.
B) Keep allowDynamicVersions Analyzer option but change the default to true and add hasLockedDependencies property to enable writing of policy rules.

[fviernau]

Not sure if I'm against it. Just share some drawbacks of a removal which come to my mind:

1. It follows less the fail early. In particular, if dependency tree changes frequently it
   can cause uncached licence / copyright scanning wasting compute and taking much longer to report the error.
2. Showing an issue for this will require to run the evaluator. (maybe not a drawback).
3. The power for the CI config administrators to say: "If don't follow our have lockfile best practice we do not spent much compute"

[mnonnenmacher]

If we have the hasLockedDependencies property on projects, we could replace allowDynamicVersions with a property like requireLockedDependencies to configure if the analyzer creates an issue if hasLockedDependencies == false and what the severity should be. Then admins could decide if this is an error or just a hint, and based on the exit code of the analyzer decide if the pipeline should continue.

[mnonnenmacher]

@oss-review-toolkit/tsc Should we collect such proposals in the ideas section of the discussion board instead of making them issues?

[sschuberth]

@oss-review-toolkit/tsc Should we collect such proposals in the ideas section of the discussion board instead of making them issues?

I have no strong preference here. If there was a quick consensus on the proposal, I would have simply removed "Proposal: " from the title to make it an issue to implement.