Our security team requires us to upgrade Python as soon as a new version comes out, but some libraries may not support it yet. We generally stay on a supported version. How can we make the case for a policy that allows time to validate dependencies?
There is also a scheduled process that removes older Python installations, so waiting to upgrade can break existing projects and virtual environments.
Ask security to distinguish the latest patch release from the latest feature release. Updating the patch version within a supported Python branch is a different compatibility risk from moving every project to a new minor version.
Python branches have published support timelines, though security-only phases and distributor support can differ. Propose a support matrix that says which branches are allowed, how quickly security fixes must be applied, and when each branch needs to be retired. You still need a migration plan, but it doesn't have to start on release day.
The deletion job is the immediate problem. Ask for a pause or an exemption for interpreters used by active projects until their replacements have passed testing. Removing an interpreter can leave virtual environments unusable, regardless of whether the application code is ready to move.
Before anything gets deleted, inventory the projects and environments tied to each installation. Then test migrations somewhere separate and schedule removal after the owners have confirmed they're ready.
Make the upgrade a joint validation process. List the dependencies that don't yet support the new Python version, run the test suite against it, and record the failures. Ask security and the application owners to agree on who accepts the risk if a deadline arrives before those issues are resolved.
That also makes the cost visible. A policy can require a date, but it can't make a dependency compatible by that date.
Don't limit the security discussion to the interpreter. Dependencies need vulnerability monitoring and updates too. Automated update proposals can help, but they still need review and tests because package upgrades can break things or introduce supply chain risk.
Dev containers could be worth discussing if workstation installs are being removed. They can give each project a defined Python environment, but they'd need to meet the same security and patching requirements. Check with security before treating them as a solution to the policy.
Answers are reviewed before publication.
q.716~turnkey:
What if security still insists on the newest minor version even when the current branch is supported?
d7+ferrule_309:
Bring a concrete exception request with the affected libraries, their compatibility status, the testing needed, and a proposed review date. That gives them a specific risk decision rather than a general argument about release policy.