Simplifies version tracking and release procedures - #3331
Merged
Merged
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Collaborator
|
This is a nice idea! |
Collaborator
Author
|
| describe config | master version |
|---|---|
--match v* (this PR, before fix) |
1.2.0.dev805+g… ❌ |
--match v* --match dummy-v* (this PR, after fix) + anchor tag |
1.10.0.dev1+g… ✅ |
A wrong base version (1.2.0) also fails diffcp's cvxpy>=1.6.3 requirement during resolution, which is the proximate cause of the red CI.
What this PR now does
describe_commandalso matchesdummy-v*— an anchor tag onmasterthat makes the most recent minor release reachable. This is additive: it does not move or touch the publishedv1.9.0tag.build.ymltag builds + theDEPLOYgate are restricted tov*, sodummy-v*tags can never trigger a PyPI deploy.
Required manual step after merge
Create the anchor tag on the master commit release/1.9.x was branched from (eb1fea237, the parent of cd95b324c):
git tag -a dummy-v1.9.0 eb1fea237 -m "setuptools-scm anchor: master 1.9 branch point"
git push origin dummy-v1.9.0
This adds no commits to master — it is a ref only. Verified locally: with this tag, master HEAD resolves to 1.10.0.dev1+gcd95b324c, and release/1.9.x still resolves to the real v1.9.0 (it is closer). Going forward, the procedure in PROCEDURES.md tags v1.10.0 directly on master, so once 1.10.0 ships no further anchor tags are needed.
Contributor
|
Benchmarks that have stayed the same: |
PTNobel
force-pushed
the
prototype/setuptools-scm
branch
from
June 6, 2026 02:23
8073f32 to
a536afd
Compare
Collaborator
Author
|
@SteveDiamond can we merge this PR? |
Replace the hand-maintained MAJOR/MINOR/MICRO/IS_RELEASED constants in setup/versioning.py with setuptools-scm. The version is now derived from git tags at build time and written to cvxpy/_version.py. PROCEDURES.md updated: release now means tagging master at the cut point instead of editing a constant. Patch tags continue to live on release/* branches; minor tags must be reachable from master so setuptools-scm's release-branch-semver scheme can find them. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Rename version_scheme from `release-branch-semver` (deprecated entry point name) to `semver-pep440-release-branch`, and move `git_describe_command` under the `scm.git` namespace as `describe_command`. Both deprecations were flagged by setuptools-scm 8.x. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add fetch-depth: 0 to actions/checkout in every workflow that builds or installs CVXPY from source, so setuptools-scm can find git tags. Without this, the shallow clone hides all tags and setuptools-scm falls back to a 0.x version, which then prevents uv from resolving diffcp>=1.1.5 (those wheels require cvxpy>=1.6.3) and downgrades to a binary-incompatible diffcp 1.1.4. - Add fallback_version = "0.0.0" so non-git source builds (GitHub tarball downloads, which aren't proper sdists) produce a working version instead of erroring out. - Fix PROCEDURES.md to reference the current scheme name semver-pep440-release-branch (matches pyproject.toml). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.1.4 ships a pybind11 M_operator binding that is incompatible with current scipy/numpy and breaks test_optional_solvers at runtime. 1.1.5 is also the first release that declares cvxpy>=1.6.3 as a runtime dep, which gives uv a second line of defense if setuptools-scm ever falls back to a 0.x version. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Real release tags live on release/* branches and are not ancestors of master, so `git describe` falls back to an ancient tag and master computes a wrong version (e.g. 1.2.0.devN instead of 1.10.0.devN). Match `dummy-v*` anchor tags in describe_command so a tag placed on the master branch point makes the most recent minor release reachable. Restrict build.yml tag builds (and the DEPLOY gate) to `v*` so dummy-v* anchor tags cannot trigger a PyPI deploy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
diffcp 1.1.5-1.1.8 declare a `cvxpy` runtime dependency, creating a circular dependency that uv cannot resolve against the cvxpy workspace project. diffcp 1.1.9 drops that dependency. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PTNobel
force-pushed
the
prototype/setuptools-scm
branch
from
June 8, 2026 19:52
a536afd to
4ad56cd
Compare
rileyjmurray
approved these changes
Jun 18, 2026
rileyjmurray
left a comment
rileyjmurray
left a comment
Collaborator
There was a problem hiding this comment.
LGTM!
(G = gorgeous.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
I was reworking the CVXPYlayers release procedures, and realized we could generate version numbers from the version control system via
setuptools-scm; I went ahead and had Claude prototype the change. I think it looks nice and seems like an improvement and figured I'd check what others think.Type of change
Contribution checklist