Skip to content

Bump rain-math-binary 0.1.1 -> 0.1.4 #556

Description

@thedavidmeister

This repo pins rain-math-binary = "0.1.1". The latest published release is 0.1.4.

The change: foundry.toml, remappings.txt, soldeer.lock, and the rain-math-binary-0.1.1/ import prefix in src/lib/op/bitwise/LibOpBitwiseCountOnes.sol, test/src/lib/op/bitwise/LibOpBitwiseCountOnes.t.sol, test/src/lib/parse/LibParseState.constantValueBloom.t.sol. Confirm that file list against the checkout rather than trusting it.

What the bump buys, and what it does not

rain.math.binary/src/ has changed once since 2024 — 90244afc (2026-07-18), NatSpec on ctpop/ctpopSlow and a comment correction. There is no behaviour change between 0.1.1 and 0.1.4. This is not a fix.

The reason to do it is that the org carries two pins of a one-library package: rainlang on 0.1.1, rainlang.interface and rain.extrospection on 0.1.3. Converging on 0.1.4 removes the split, so the next bump — one that does change behaviour — is a single coordinated move rather than a reconciliation.

Why this cannot be judged repo-locally

Soldeer is flat, and foundry resolves a dependency's imports using the CONSUMER's remappings. Every repo pulling this one must therefore declare rain-math-binary at exactly the version this repo's import paths name. That is why raindex, rain.erc4626.words, rain.flare, rain.merkle and rain.pyth all pin 0.1.1 while referencing LibCtPop nowhere themselves.

Merging this does not break them — they keep building against the release of this repo they already pin — but each needs its own pin moved to 0.1.4 when it next takes a release of this repo. That coordination is the cost, and it belongs in the PR body.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions