Skip to content

[v1.x] docs: pin mkdocs<2#3074

Merged
maxisbey merged 1 commit into
v1.xfrom
docs-pin-mkdocs-1x-v1x
Jul 7, 2026
Merged

[v1.x] docs: pin mkdocs<2#3074
maxisbey merged 1 commit into
v1.xfrom
docs-pin-mkdocs-1x-v1x

Conversation

@maxisbey

@maxisbey maxisbey commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Backports the mkdocs<2 bound from #3072 to the v1.x line.

Motivation and Context

"MkDocs 2.0" is a ground-up rewrite that removes the plugin system, so it's incompatible with mkdocs-material and the docs plugin stack (context in #3072). This branch's docs group had an unbounded mkdocs>=1.6.1; today it's protected only by the frozen lockfile and transitively by mkdocs-material 9.6.x's own mkdocs~=1.6 requirement. Pinning the direct dependency makes the guard explicit so a future re-lock on this branch can't resolve 2.0.

No locked versions change — the diff is the specifier plus its lockfile manifest entry. The advisory-banner silencing from #3072 isn't needed here: v1.x locks mkdocs-material 9.6.19, which predates the banner.

How Has This Been Tested?

uv lock re-resolves cleanly with the new bound (mkdocs stays 1.6.1); pre-commit's lock consistency check passes.

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

MkDocs 2.0 is a ground-up rewrite that drops the plugin system, so it is
incompatible with mkdocs-material and the rest of the docs plugin stack.
Mirror the bound from main (#3072) on the direct dependency so a future
re-lock on this branch cannot resolve 2.0. The locked versions are
unchanged; today the branch is protected only transitively by
mkdocs-material 9.6.x's own mkdocs~=1.6 requirement.
@maxisbey maxisbey marked this pull request as ready for review July 7, 2026 12:48
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation preview

Preview https://pr-3074.mcp-python-docs.pages.dev
Deployment https://666a57b8.mcp-python-docs.pages.dev
Commit 95e7ff9
Triggered by @maxisbey
Updated 2026-07-07 12:49:23 UTC

@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

@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 — straightforward docs dependency pin (mkdocs<2), no locked versions change.

Extended reasoning...

Overview

This PR only touches the docs dependency group: it adds an upper bound mkdocs>=1.6.1,<2 in pyproject.toml (with an explanatory comment) and the corresponding manifest specifier line in uv.lock. No locked package versions change; mkdocs remains 1.6.1 in the lockfile. It is a backport of the same bound already applied on the main line in #3072.

Security risks

None. The change constrains an existing docs-only dev dependency to its current major version — it does not introduce new packages, upgrade anything, or affect runtime code in src/mcp.

Level of scrutiny

Low. This is a two-line specifier change in packaging metadata for the documentation build, guarded further by the frozen lockfile and mkdocs-material's own mkdocs~=1.6 constraint. There is no logic, no runtime path, and no test surface affected.

Other factors

The bug hunting system found no issues, the PR description confirms uv lock re-resolves cleanly and the lock consistency check passes, and the diff exactly matches the stated intent. There are no outstanding reviewer comments.

@maxisbey maxisbey merged commit ba33472 into v1.x Jul 7, 2026
31 checks passed
@maxisbey maxisbey deleted the docs-pin-mkdocs-1x-v1x branch July 7, 2026 12:52
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.

1 participant