feat: added python-version-strategy config option, to enable enforcing use of the lowest supported (approximate) version

[ErikBjare]

Description:

Adds a python-version-strategy config option that enables overriding the version-picking strategy provided by the Python version specifier from >= and ^ to ~.

This is very useful when the version specified in python-version-file is a version constraint such as ^3.8 but where you usually want to test against the lowest supported version (with the highest patch version).

Related issue:

Filed a feature request for this here: #774

Check list:

• Mark if documentation changes are required.
  • Not done, yet (will do if PR is likely to be accepted)
• Mark if tests were added or updated to cover the changes.
  • Not done, yet (will do if PR is likely to be accepted)

PRs I will merge if this change is accepted:

• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-core#124
• ci: poetry caching and python-version-file ActivityWatch/aw-client#80
• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-qt#101
• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-server#148
• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-watcher-afk#65
• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-watcher-window#93
• ci: replaced python_version matrix var with `python-version-file: p… ActivityWatch/aw-watcher-input#29

[ErikBjare]

Might be better to make the versionStrategy directly take ~ as an argument, so that it can be used for all kinds of version overrides.

Not sure if there are uses for overriding the strategy to ^ however.

[gowridurgad]

Hi @ErikBjare, Thanks for the contribution.

The behavior this PR aims to override follows the action’s existing SemVer-based version resolution: a caret range like ^3.8 is treated as a compatible range and can resolve to the newest satisfying version within it, whether it comes from python-version or python-version-file. Reinterpreting that inside the action would change the semantics of the version declared in the source file rather than simply reading it as written.

Users who want minimum-compatible behavior can express that directly with a narrower specifier such as ~3.8 or 3.8.

Since the underlying feature request in #774 was closed as not planned on that basis, this PR does not have a path to merge. Closing this out accordingly.