Skip to content

chore(master): release 2.1.0#1165

Open
github-actions[bot] wants to merge 1 commit intomasterfrom
release-please--branches--master
Open

chore(master): release 2.1.0#1165
github-actions[bot] wants to merge 1 commit intomasterfrom
release-please--branches--master

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot commented Mar 30, 2026

🤖 I have created a release beep boop

2.1.0 (2026-04-01)

Features

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

Bug Fixes

  • 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


This PR was generated with Release Please. See documentation.

@github-actions github-actions bot force-pushed the release-please--branches--master branch from b404fd7 to d77b2f6 Compare April 1, 2026 17:48
@MilesCranmer
Copy link
Copy Markdown
Owner

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

@MilesCranmerBot
Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants