Set Development Status classifier to Production/Stable#2975
Conversation
The classifier reflects project maturity, not the pre-release stage of a given version — that's what the PEP 440 version segment (a1/b1/rc1) is for. This matches the convention followed by pydantic, aiohttp, SQLAlchemy, numpy, pip, etc., and removes a manual per-stage edit from the release process (which is otherwise tag-only via uv-dynamic-versioning). Reverts the classifier portion of #2831 and removes the corresponding release-checklist step.
There was a problem hiding this comment.
LGTM — metadata-only change; the classifier swap and RELEASE.md cleanup are consistent and well-motivated.
Extended reasoning...
Overview
This PR touches only two files: pyproject.toml (changes the Development Status trove classifier from 3 - Alpha to 5 - Production/Stable) and RELEASE.md (removes the now-obsolete step instructing maintainers to flip the classifier per release stage). It is a partial revert of #2831, with the doc edit keeping the release process consistent with the metadata change.
Security risks
None. Trove classifiers are purely informational PyPI metadata — no installer or resolver acts on them, and no code paths are affected.
Level of scrutiny
Minimal scrutiny is appropriate: this is a packaging-metadata and documentation change with no runtime, build, or dependency impact. The PEP 440 pre-release version segment continues to carry the per-artifact stability signal, so there is no risk of users accidentally installing pre-releases due to this change. The only consideration is the policy question of whether the project wants to advertise itself as Production/Stable while shipping v2 alphas, which the PR description addresses thoroughly with ecosystem precedent.
Other factors
The two edits are internally consistent (removing the manual classifier-flip step matches making the classifier static), the change is small and self-contained, and the bug-hunting pass found no issues.
…fier - publish-pypi: build both packages into one dist/ and publish in a single step with skip-existing, so a partially failed upload is fixed by re-running the job rather than by step ordering. - mkdocs: drop the watch package list instead of extending it. - The Development Status classifier is permanently 5 - Production/Stable; say so in RELEASE.md and set it on mcp-types, which #2975 left at Alpha.
|
This pull request is included in pre-release v2.0.0a3 |
…fier - publish-pypi: build both packages into one dist/ and publish in a single step with skip-existing, so a partially failed upload is fixed by re-running the job rather than by step ordering. - mkdocs: drop the watch package list instead of extending it. - The Development Status classifier is permanently 5 - Production/Stable; say so in RELEASE.md and set it on mcp-types, which #2975 left at Alpha.
Sets the
Development Statustrove classifier to5 - Production/Stableand removes the per-stage classifier-flip step fromRELEASE.md. Reverts the classifier portion of #2831.Motivation and Context
#2831 set this to
3 - Alphaon the basis that we're publishing alphas. After looking into it more, the ecosystem convention is overwhelmingly to treat this classifier as project maturity, not the pre-release stage of a given artifact:5 - Production/Stable: pydantic 2.0a1, aiohttp 4.0.0a1, SQLAlchemy 2.1.0b2.a1→ excluded without--pre) and PyPI's pre-release banner.dynamic = ["version"]viauv-dynamic-versioning); flipping the classifier per stage was the one remaining manual source edit.PEP 792 does note that trove classifiers are mechanically per-distribution rather than project-wide — but treats that as a limitation, which is why it introduced project-status-markers as the replacement mechanism.
Companion: #2976 bumps
v1.xthat branch from4 - Beta(unchanged since Nov 2024) to5 - Production/Stableas well.How Has This Been Tested?
n/a — metadata only.
Breaking Changes
None.
Types of changes
Checklist
Additional context
AI Disclaimer