server.json has a version_detail.version field that is currently just defined as a string, with a rough expectation that it is some flavor of SemVer.

@jonathanhefner raised:

Is there any place that we specify the version number format? For example, would we support "1.0.0-alpha" => "1.0.0-beta"?

@joelverhagen:

I had assumed SemVer, but this is a nuanced problem. I imagine folks will want to use the same version string as the underlying package for simplicity. And there is no guarantee of a unified version model for N package ecosystems. For example NuGet is SemVer-ish with case insensitive and a 4th version digit supported.

Perhaps complaint SemVer 2.0.0 for MCP Registry, and build metadata rejected? (1.0.0-alpha but not 1.0.0-alpha+foo which SemVer 2.0.0 supports but adds complexity).

Me:

I think it is actually unlikely that folks will want to bind the MCP server version with their package version. There may be cases where the MCP server version gets incremented even though the code doesn't change (for example, in the case of me deciding to update the description. It would be limiting myself to require that I make a code change to make that MCP server-level metadata change.

@jonathanhefner here:

Actually, from the end user's perspective, I think it would be preferable to allow any format. I think the core issue is how the registry tracks version history.

The FAQ says version numbers should be "bumped" or "incremented", which, obviously, requires version numbers to have an ordering scheme. However, since the registry only tracks which version is "latest" (i.e. doesn't support branching), we could just base "latest" off of the submission date, and change the version number requirement to "unique" instead of "incremented". But perhaps the intention was to leave the door open to support branching in the future?

I had said this would be a fast-follow to #153 but I think it merits its own discussion as an Issue first