Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.79%. Comparing base (bfba965) to head (65bfddf).

@@           Coverage Diff           @@
##             main    #6516   +/-   ##
=======================================
  Coverage   97.79%   97.79%           
=======================================
  Files        1124     1124           
  Lines       95705    95707    +2     
=======================================
+ Hits        93595    93597    +2     
  Misses       2110     2110           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thank you @pavoljuhas for working on making Cirq Python 3.12 compatible. I see that some packages were bumped in order for tests to pass. Is there a policy for updating Cirq dependencies? For example,

• I use poetry to manage my packages, which makes updating to the latest version feasible by the command poetry update.
• Dependabot and Renovate do this too, as bot contributors to the repo ( i.e. they create their own PRs whenever an update is possible )

Thank you @pavoljuhas for working on making Cirq Python 3.12 compatible. I see that some packages were bumped in order for tests to pass. Is there a policy for updating Cirq dependencies? For example,

• I use poetry to manage my packages, which makes updating to the latest version feasible by the command poetry update.
• Dependabot and Renovate do this too, as bot contributors to the repo ( i.e. they create their own PRs whenever an update is possible )

Thank you for your comment. In general we try to follow the NEP-29 version policy for Python and NumPy. As for other packages, we seek to use loose version specifications, e.g., somepackage~=1.2 to freeze the major version but match recent minor releases which in theory should have compatible APIs. Cirq is often used as a library that should be installable with other projects so we do not want to restrict its dependency specifications more than needed. If there is a breaking change for some third-party release, we add an upper bound for the last working version. These rules have a tendency to get outdated, which is a part of the process that could be improved.
We revisit dependencies at the release time or when there is a need for major-version upgrade of some package.

In regards to the poetry, the poetry update creates a lock file with exact versions of all direct and transitive dependencies at the time of execution - which is useful for reproducible installations. The lock files are resolved from package version constrains in pyproject.toml which need manual updates so that part of labor seems to be the same.

It would be nice to get notifications when our requirement specs exclude the latest stable releases.
We are glad to consider suggestions if you (or others) know of such tool.

Thank you for the thorough answer @pavoljuhas. My suggested approach would be either Dependabot or Renovate, as they generate small PRs which only update the relevant versions, making it easier to approve/reject version bumps. Usually it's nice to limit these to major versions, otherwise we get flooded with these PRs, and as maintainers there are more important things you can focus on :) I'd recommend:

1. Creating an issue to automatise version updates through Dependabot / Renovate / maybe even snyk for vulnerability detection, so that maintainers don't have to spend time on it when needed. It is not urgent, so it would probably sit in the backlog until someone wants to take this work, as it should.
2. Merging this PR as is. It is independent of the above

Do you want me to create the issue?