Skip to content

Set Development Status classifier to Production/Stable#2975

Merged
maxisbey merged 1 commit into
mainfrom
dev-status-classifier-stable
Jun 25, 2026
Merged

Set Development Status classifier to Production/Stable#2975
maxisbey merged 1 commit into
mainfrom
dev-status-classifier-stable

Conversation

@maxisbey

@maxisbey maxisbey commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Sets the Development Status trove classifier to 5 - Production/Stable and removes the per-stage classifier-flip step from RELEASE.md. Reverts the classifier portion of #2831.

Motivation and Context

#2831 set this to 3 - Alpha on 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:

  • Of 22 major projects surveyed, only Django flips it per release stage; the other 19 (pip, setuptools, numpy, pandas, scipy, scikit-learn, matplotlib, Flask, FastAPI, aiohttp, SQLAlchemy, pydantic, httpx, anyio, attrs, hatch, etc.) keep it constant across pre-releases and finals.
  • The closest analogues to our v2 — major-version rewrites of foundational libraries — all shipped pre-releases as 5 - Production/Stable: pydantic 2.0a1, aiohttp 4.0.0a1, SQLAlchemy 2.1.0b2.
  • No installer or resolver (pip, uv, poetry, pdm, flit, hatch) reads this classifier; PyPI uses it only as a search-filter facet. The per-artifact stability signal is already carried by the PEP 440 version segment (a1 → excluded without --pre) and PyPI's pre-release banner.
  • Our release process is otherwise tag-only (dynamic = ["version"] via uv-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.x that branch from 4 - Beta (unchanged since Nov 2024) to 5 - Production/Stable as well.

How Has This Been Tested?

n/a — metadata only.

Breaking Changes

None.

Types of changes

  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling — n/a
  • I have added or updated documentation as needed

Additional context

AI Disclaimer

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.
@maxisbey maxisbey marked this pull request as ready for review June 25, 2026 17:44

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

Re-trigger cubic

@maxisbey maxisbey merged commit 603342f into main Jun 25, 2026
35 checks passed
@maxisbey maxisbey deleted the dev-status-classifier-stable branch June 25, 2026 21:47
maxisbey added a commit that referenced this pull request Jun 26, 2026
…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.
@github-actions

Copy link
Copy Markdown
Contributor

This pull request is included in pre-release v2.0.0a3

maxisbey added a commit that referenced this pull request Jun 26, 2026
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants