Specify pyaaf2 requirement as a minimum version

[AWhetter]

Summarize your change.

bb60a6f loosened the versions of packages that are required, and changed the specification of dependency versions from being exact versions to being minimum versions. However the same change was not applied to the pyaaf2 version specification. Given that pyaaf2 versions have remained backwards compatible, at least so far, it should be safe to allow users to use different versions of pyaaf2 than what is required in the setup.py currently. Therefore this change makes the version requirement of pyaaf2 also be a minimum version specification rather than an exact one.

Reference associated tests.

None required.

[codecov-io]

Codecov Report

Merging #906 (435a5e3) into master (3c1e28e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #906   +/-   ##
=======================================
  Coverage   85.97%   85.97%           
=======================================
  Files         184      184           
  Lines       17883    17883           
  Branches     1992     1992           
=======================================
  Hits        15375    15375           
  Misses       2000     2000           
  Partials      508      508           

Flag	Coverage Δ
unittests	85.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3c1e28e...435a5e3. Read the comment docs.

[ssteinbach]

In the past, breaking changes to PyAAF versions created mysterious errors in PR unit test runs. Locking the version was an attempt to prevent that. I think if we were going to unlock it in this way we'd want to enable a nightly build or similar thing so that we could catch failures related to dependencies changing outside of PRs breaking because of upstream libraries changing.

[reinecke]

@ssteinbach In those previous cases would semver have signaled those issues? If so, maybe we could do something like: pyaaf2~=1.4.0 to pick up patch releases but make sure we stay in the 1.4.x version series.

[ssteinbach]

I think they were the middle digit changing. I'd have to go and look through the history to confirm that. To be honest, I don't think PyAAF2 releases all that often (I think the most recent release is still 1.4.0 from last january), but if the pattern you're suggesting means 1.4.x that seems relatively safe. I think there are also GitHub ways of detecting that a dependency has made a release and if the unit tests pass automatically landing a PR that bumps the version up. I'd love a solution like that.

[reinecke]

I agree. I think we could accept this PR by having it use ~= instead of >=. The re-build thing would be a great nice-to-have, but if someone is having pain because of our stale specific version pinning, I'd hate for them to be stuck. @AWhetter how does this sound to you?

[AWhetter]

Seems sensible to me. I've made the change to ~=.

[ssteinbach]

Just for future reference, this was the service I was mentioning: https://github.com/dependabot

[ssteinbach]

better docs: https://docs.github.com/en/code-security/supply-chain-security/enabling-and-disabling-version-updates#enabling-github-dependabot-version-updates

[ssteinbach]

Thanks @AWhetter!