mirror of
https://github.com/renovatebot/renovate.git
synced 2026-11-02 10:33:39 +00:00
Jamie Tanna
e942788539
* test(datasource/pypi): cover which `upload_time` a version reports As part of future changes to how we calculate the `releaseTimestamp`, it was clear we don't have as much coverage of this logic. To make this more explicit, we can add new test coverage. Additionally, we can introduce a new example from a package to guide this. Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io> * fix(datasource/pypi): use the earliest `upload_time` of a version When calculating the `releaseTimestamp` for the PyPI datasource, we've been looking at the first entry in the response, which isn't always the first time this package existed. In the case that a Wheel is uploaded after the package first was released - for instance, to support a new version of Python, at an existing pinned version of the package - this would lead to a potentially incorrect calculation for the `releaseTimestamp`. This can lead to Renovate seeing a package as newer than it is, which can mean that i.e. `minimumReleaseAge` can show as pending for a package that shouldn't be. As part of upstream changes[0], this should be less frequent in the ecosystem, but existing packages still exist with this behaviour. To fix this, we can make sure that we filter a given Release's to find the earliest `upload_time`. Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io> [0]: https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/ --------- Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>