Every star on the repo with its exact timestamp, bucketed by week (Monday to Sunday), next to PyPI downloads and the release timeline — so each release can be read against what it actually moved.
Printed from the interactive report. In the live page the range controls filter every chart and table, the charts have hover detail, and the download chart can switch to the dependency-adjusted series.
Bars are new stars. The dashed line is the mean for the selected range; dotted verticals mark releases. Turn on posts to see what was published each week: one dot per post, sized by reach: violet for release announcements, amber for demos, teal for explainers that teach how tracking works, grey for everything else. Hover a week for the detail.
Cumulative stars at the close of each week.
7-day trailing mean, mirrors excluded. PyPI keeps only the last 180 days, so the chart is a rolling window and older releases drop off its left edge. On 2026-03-27 inference and inference-gpu 1.2.0 added trackers~=2.3.0 as a dependency, and the line steps that day: from then on an unknown share of these downloads is machines installing inference, not people installing trackers. Estimated organic subtracts the part that moves with inference's own download volume (least squares, 0.0382 downloads per inference install) — a rough correction, not a measurement, and it is fitted only on the days between the two red lines. On 2026-08-24 PyPI itself changed what counts as a download: only requests for an actual .whl, .tar.gz or .zip are recorded now, so metadata reads stopped counting. PyPI calls that discontinuity permanent, and it hit these packages very unevenly — see the note under the chart. Nothing either side of that line is comparable. Turn on posts to see what was published each day, with the same colours and sizing as the star chart.
Extra stars counts the 14 days from the release and subtracts what the 3 preceding weeks predicted (their median daily rate). Times the normal rate is that same window divided by the baseline. The baseline is the median daily rate of the 21 days ending 2 days before the release, times 14 — median rather than mean so that an earlier spike does not inflate it. Hover any column header for its definition, or the extra-stars number itself to see the whole calculation for that release, both windows included. Promo is the first LinkedIn or X post announcing the release, how many days after PyPI it went out, how many posts the team published, and their combined reactions. Best day is the single biggest day in the window and how long after the release it arrived.
| Release | What shipped | On PyPI | Promo | Best day | Extra stars, 14 days | Times the normal rate |
|---|
Every LinkedIn and X post I could measure, so the numbers above can be checked against what was actually published. Reach is impressions on LinkedIn and views on X — both from account analytics for Alex, and from the public view counter for Piotr's posts. Links open the post where one is available.
| Date | Where | Post | Release | Reach | Reactions | Replies | Shares |
|---|
Each release owns the days until the next one ships. Front-loaded is the share of the cycle's stars that arrived in the first 14 days — high means the release was an event and then went quiet, low means it kept pulling. 2.0.1 is folded into 2.0.0 (one day apart).
| Release | Cycle length | Stars in cycle | Stars per day | Front-loaded | Downloads per day | Vs. prev cycle |
|---|
Stars measure arrival. This measures the people already using the library. Bugs hit in 14 days counts only people who ran into the problem while using the library; proactive source audits are counted separately, since they say something about attention on the code, not about the release breaking; community PRs counts pull requests from outside the core team, per 30 days so long and short cycles compare; feature requests are users asking for more, which is a sign of use, not of failure. A release can be quiet in stars and still land well here — and the two are not the same thing. Hover a bug count to see the issues behind it: the bar on the left is how much attention each one drew, counting a reaction as twice a comment, since a reaction is usually someone saying it happened to them too.
| Release | Cycle | Community PRs | Bugs hit in 14 days | Feature reqs | Questions | People | Median close |
|---|
GitHub reports who sent visitors to the repo. This is the closest thing to a click-through rate: X and LinkedIn do not expose per-post link clicks, so the honest measure is how many people arrived, not how many tapped. GitHub keeps only 14 days, so the pipeline snapshots it every run — a missed week is a permanent gap.
A pre-registered test, written down before the data came in. The question is whether posting consistently between releases lifts the ordinary week, so weeks containing a release are excluded from both sides.
| Week starting | New stars | Running total | Change vs prev week | % change | Growth on total |
|---|