• v0.29.0 67c5901f05

    0.29.0 — two-item core
    All checks were successful
    CI / gate (push) Successful in 53s
    CI / image (push) Successful in 21s
    Stable

    joeyr released this 2026-09-02 20:46:01 -05:00 | 496 commits to main since this release

    Changed

    order.core is the first two completed items instead of the first three. CORE_ITEM_COUNT is the only boundary between core and late, and both are slices of one walk over the purchase sequence, so nothing is dropped — the third item moved into late, which keys per item rather than per sequence and therefore does not split.

    A core sequence is an ordered key, so its domain grows with every slot it carries and the sample behind each published row shrinks. Measured on the 16.17 file over the 81 champion-roles with 50 or more sampled build orders:

    core length distinct sequences modal row's share median games behind it top four rows cover
    3 (0.28.0) 36.3 18.2% 12 44.4%
    2 (0.29.0) 20.1 37.6% 27 69.1%

    Since lol-companion renders the top four rows, the build strip goes from describing under half of the sampled games to roughly seven in ten, and the games figure printed on the core block roughly doubles.

    order.late.games widens with it. Its denominator was sampled games that reached a fourth completed item and is now those that reached a third, so the situational half is measured over more games as well.

    Nothing is re-crawled for this. item_order is stored raw and classified at build time, so the next nightly run rebuilds the file with two-item cores over the whole retained window.

    Unchanged

    • LATE_ITEM_CAP stays at 9. A consumer rendering six unique items has to skip a late row for each core item it already displayed, so the cap has to clear six plus the core length; a shorter core only widens that margin.
    • lol-companion needs no change. Its builds adapter maps whatever itemIds the row carries, and its Situational block was already sized at six.
    Downloads