PyPI Now Rejects New Files on Releases Older Than 14 Days
PyPI Blog: Releases now reject new files after 14 days

To prevent supply chain attacks, PyPI now blocks new file uploads to releases older than 14 days. This change follows compromises of LiteLLM and Telnyx, aiming to stop attackers from poisoning long-stable packages. While some projects previously added new Python versions to old releases, data showed this practice was rare. We advise users not to rely on this behavior yet, as formal semantics for closed releases are still being defined under PEP 694.
The rough consensus of the discussion was that the summit attendees thought it was acceptable to require users to bump to the next version to support new Python versions.
- yladiz
I’m a bit surprised this is possible in the first place. I get that you might not be able to upload everything in one go, but it feels like you should “start” and “finish” a release in that case, and once it’s finished you can’t modify it.
I guess the use case is that you might want to build a wheel for an older release for a newer version of Python?
- firesteelrain
This seems like common sense configuration management 101. If I download v1.2 and it’s been published then it should be considered released and not modifiable. With exceptions for ‘dev’ releases of course. I have never published anything on PyPI but I would expect there is a publish button and finalize (?) optional button that if not checked after 14 days makes it final ?
- edelbitter
> To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases
While this may quantify how disruptive the change would be to those projects that are able to and do upload additional binaries to PyPI later, it fails to quantify how many projects already completely circumvent this block before it is even introduced.
e.g. If you tell pip to install from source.. the result may already be that you install a binary that PyPI never saw. A common hack for dealing with NVidia internals, which can explode into a large CUDA major version x GPU arch x platform x implementation x python_version cartesian product. The "extras" mechanism is not quite sufficient to model such combinations.
sample code:
https://github.com/Dao-AILab/causal-conv1d/blob/4f6ae4e26ae5...