chore(master): release 2.1.0

[github-actions]

🤖 I have created a release beep boop

2.1.0 (2026-04-19)

Features

• add slurm tests using docker compose (0364d43)
• raise friendly error when loss functions have bad signatures (#1138) (1e18b9a)

Bug Fixes

• correct type in elementwise loss validation (#1184) (912c4c2)
• normalize DataFrame column spaces in predict (#1136) (3bffc62)
• torch export with constant arguments (bb721b5)
• torch export with constant arguments (e280034)
• typing issue in export format (2b173ff)

Documentation

• add example paper on active matter (#1107) (37b2d85)
• add example paper on Lya forest analysis (#1098) (b4e7db3)
• add example paper on SR for batteries (#1074) (f567e7c)
• add implied volatility showcase paper (#1172) (c435527)
• add language picker (9227472)
• add math discovery paper (#1156) (95ffa50)
• clean up splash page and reorg sidebar (c5531f9)
• fix api docs generation (19dc565)
• fix image paths (71d5c2e)
• fix paper rendering (0f924f6)
• fix paper styling (dfe08af)
• fix preview deployment for both targets (356ddb9)
• fix readme link (d071b3e)
• fix redirect (fac6aab)
• fix splash page (47a8dab)
• generic cleanup (a879aea)
• include version picker (a76e11b)
• move markdown to separate file (31c75af)
• overhaul to vitepress (f7b8725)
• refactor to clean up docs (27ac0db)
• revert additional pieces of template (a206b11)
• revert image issue (1e21305)
• set canonical url (5c3d3f1)
• set error when no key (45025eb)
• tweak splash page logo (342f35e)
• use DocumenterVitepress.jl to build pysr docs (2853c50)

---

This PR was generated with Release Please. See documentation.

[MilesCranmer]

@MilesCranmerBot do you know why this isn't creating the next alpha release instead? Should it be?

[MilesCranmerBot]

I think this is a release-please prerelease/version-parsing mismatch.

Why it generated 2.1.0:

• release-please-config.json is set to prerelease mode ("versioning": "prerelease", "prerelease": true).
• But .release-please-manifest.json currently says 2.0.0a2.
• In release-please, the generic version parser only recognizes SemVer-style prereleases like 2.0.0-alpha.2 (it looks for a -... prerelease suffix), not PEP 440 a2.
• So 2.0.0a2 gets effectively treated like plain 2.0.0, and with a feat in the changelog it bumps to the next stable minor: 2.1.0.

So yes: if the intent is to stay on the alpha track, this probably should be the next alpha instead of a stable 2.1.0.

I don’t think this is your repo config doing something especially weird — it looks more like release-please’s prerelease strategy is SemVer-oriented, while PySR is using PEP 440-style Python prerelease versions.

[MilesCranmer]

I think this is a release-please prerelease/version-parsing mismatch.

Why it generated 2.1.0:

• release-please-config.json is set to prerelease mode ("versioning": "prerelease", "prerelease": true).
• But .release-please-manifest.json currently says 2.0.0a2.
• In release-please, the generic version parser only recognizes SemVer-style prereleases like 2.0.0-alpha.2 (it looks for a -... prerelease suffix), not PEP 440 a2.
• So 2.0.0a2 gets effectively treated like plain 2.0.0, and with a feat in the changelog it bumps to the next stable minor: 2.1.0.

So yes: if the intent is to stay on the alpha track, this probably should be the next alpha instead of a stable 2.1.0.

I don’t think this is your repo config doing something especially weird — it looks more like release-please’s prerelease strategy is SemVer-oriented, while PySR is using PEP 440-style Python prerelease versions.

@MilesCranmerBot could you fix this please?

[MilesCranmerBot]

I tracked this down to the repo-side manifest drift, not just the release-please parser mismatch. I pushed a fix here: #1185

That PR stops backend update PRs from mutating .release-please-manifest.json, keeps the manifest aligned with actual released versions, and restores the pending release metadata to 2.0.0a2 so PySR stays on the alpha track.

I also prepared the direct fix on the release PR branch locally, but the token available to me here does not have permission to push to MilesCranmer:release-please--branches--master (403). If you want, I can also give you the exact commit SHA/patch to apply there.