API backward compatibility and release processes

[verult]

Is your design idea/issue related to a use case or problem? Please describe.
After Cirq 1.0, changes to cirq-core will be backward-compatible for all minor and patch version bumps. Open questions:

• What's the scope of backward compatibility?
  • To what extent can implementation logic change?
  • Need to write down JSON serialization backward compatibility policy. JSON backwards compatibility policy and tooling. #4321
• How can we enforce backward compatibility? What CI checks do we need?
• What's the process for making an urgent patch release?

[vtomole]

Thanks for opening this @verult. This is an excellent question. What's numpy's answer to this? Adding a discuss tag for tomorrow (if we have time)

[dstrain115]

Per @verult these are outstanding questions regarding the backwards compatibility policy. Since backwards compatibility policy is already stated, and these are corner cases, I recommend closing this. I doubt we will be able to have a fully specified policy as there will always be judgment calls at some level. Assigning to @pavoljuhas with recommendation to close.

[mhucka]

Discussed in Cirq Cynq 2025-01-22. The last comment by @dstrain115 summarizes the situation; the policy described at https://quantumai.google/cirq/dev/versions is still the state of things, and the consensus is that we will continue to try to follow that policy to the extent possible.