Skip to content

Conversation

@notlesh
Copy link
Contributor

@notlesh notlesh commented Aug 20, 2025

This PR adds functionality to normalize release version strings.

Context: polkadot-sdk has a different scheme for their release names and tags compared to the prdoc versions and this was causing a lot of confusion (for humans (me) and AI).

  • Release/tags follow polkadot-stable123 scheme
  • prdoc dir structure follows stable123 scheme

For example, the polkadot-stable2503 release is found here: https://github.com/paritytech/polkadot-sdk/releases/tag/polkadot-stable2503

...but the prdocs for this release are found here: https://github.com/paritytech/polkadot-sdk/tree/master/prdoc/stable2503

So this PR introduces a normalization scheme to strip polkadot- to avoid this confusion when looking for prdocs.

@notlesh notlesh requested a review from elfedy August 20, 2025 21:49
.unwrap_or_else(|| "default".to_string())
}

/// Fetches and analyzes PRDocs for a specific Polkadot SDK release.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe describing this in the tool and arguments is good enough as the explanation is a bit duplicated along the way

let project_name = get_project_name();

// Create directory under ~/.substrate-mcp/{project}/releases/{release}/pr-docs
// We use the normalized release name for the directory structure
Copy link
Collaborator

Choose a reason for hiding this comment

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

This comment might be redundant given variable name + comments above

// This strips prefixes like 'polkadot-' that users might include from git tags
let normalized_release = normalize_release_input(release);

log::info!("Fetching release '{normalized_release}' (normalized from '{release}')");
Copy link
Collaborator

@elfedy elfedy Aug 21, 2025

Choose a reason for hiding this comment

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

We should not log things to stdout as this uses the stdio transport. Client spawns a subprocess and communicates via stdin/stdout streams. Anything that goes there that is not mcp communication related might lead to unexpected behavior. If we want to implement logging we need a handle to the server and call notify_logging_message or log to stderr. See here
Although probably the tool call in this case is explicit enough to not require logging.

@snowmead snowmead closed this Sep 18, 2025
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.

4 participants