update-nlopt

name	update-nlopt
description	Bump the vendored nlopt C library (extern/nlopt submodule) to a new upstream release, and understand how that flows through to a PyPI publish. Use when asked to "update nlopt", "bump nlopt version", or similar.

Updating the vendored nlopt version

This package wraps the upstream C library nlopt, vendored as the extern/nlopt git submodule. The Python package version is not tracked separately — setup.py derives it at build time by regex-parsing NLOPT_MAJOR_VERSION / NLOPT_MINOR_VERSION / NLOPT_BUGFIX_VERSION out of extern/nlopt/CMakeLists.txt. There is no pyproject.toml version, no __init__.py version, nothing else to edit for a routine bump.

1. Bump the submodule to a specific release tag

Pin to an exact upstream tag rather than git submodule update --remote (which floats to the tip of whatever branch the submodule tracks, potentially landing on unreleased commits past the last tag):

cd extern/nlopt
git fetch --tags
git tag --list "v*" --sort=-v:refname | head   # find the latest release tag
git checkout vX.Y.Z
cd ../..
git add extern/nlopt
git commit -m "Bump nlopt submodule to vX.Y.Z"

Sanity-check the version macros landed correctly:

grep -oP 'NLOPT_(MAJOR|MINOR|BUGFIX)_VERSION *"\K[^"]+' extern/nlopt/CMakeLists.txt

This should print the three version components matching the tag you checked out — this is exactly what setup.py and the CI "already published on PyPI" guard (.github/workflows/wc-build.yml, "Ensure version is not already published on PyPI" step) both parse to compute the package version.

2. Check whether CI's OS/Python matrix needs touching

Almost never required for a routine nlopt bump — only if the new release changes which Python versions or platforms are supported:

• .github/workflows/build.yml — os / python-versions inputs passed to the reusable wc-build.yml, used for PR builds and release-triggered publishes.
• .github/workflows/manual-deploy.yml — the same OS/Python choices, exposed as workflow_dispatch checkboxes for on-demand testpypi/pypi builds.

There is no manylinux Dockerfile step anymore (CI uses the prebuilt quay.io/pypa/manylinux_2_28_x86_64 / ..._aarch64 images directly in wc-build.yml) and no hardcoded CIBW_BUILD list to hand-edit — it's derived from the python-versions input.

3. Verify via CI, not locally

Push the branch and open a PR against master. build.yml's pull_request trigger runs wc-build.yml with target: none, which builds wheels across the full OS/Python matrix and runs extern/nlopt/test/t_python.py against each installed wheel — this is the real regression check. test_scripts/sample_test_script.py is available as an optional extra manual smoke test if you want to exercise a specific solver locally.

4. Optional dry-run publish

Trigger manual-deploy.yml via workflow_dispatch with target: testpypi to validate the full build+upload path (including the version-suffix auto-generation for testpypi's 14-day immutability rule) before a real release.

5. Real release

Cut a GitHub Release (tag vX.Y.Z, matching the nlopt version). build.yml's release: published trigger runs wc-build.yml with target: pypi, which builds, tests, and publishes via trusted OIDC publishing — no manual twine upload needed.