From f4bfe7b2af53d7e9f6445a5222acc9d23080bf28 Mon Sep 17 00:00:00 2001 From: Roberto Iskandarani Date: Tue, 8 Sep 2026 14:57:22 -0300 Subject: [PATCH] docs: record 0.1.0 on main as a first release, matching the family MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit main has carried the released notes under [Unreleased] since the release: 0.1.0 was stabilized on its own branch and the commit that renamed the heading lives only there, so nothing carried it home. The heading is not all that was wrong. The section had `### Changed` with a **Migration** note and `### Fixed` with two entries — on a *first* release. Changed relative to what? There was no prior published version. The migration note tells an operator to migrate from nothing, and "the SDK no longer silently reconciles them" describes behaviour that, publicly, never existed. Those entries were deltas against internal pre-release states, which is history a reader of this repository cannot see. python-sdk, ts-sdk and go-sdk all get this right: their 0.1.0 section is a heading, a blank line, and `- Initial release.` — no subsections at all. This now matches, byte for byte in shape. Nothing of value is lost. A changelog records deltas, and a first release has none; what the SDK *does* belongs in the README and the user guides, which carry it. The entries removed here described the behaviour 0.1.0 shipped with, not a change to it. ## Deliberately not byte-exact with the tag The convention is that main's `## [X.Y.Z]` section is a byte-exact copy of the tagged one, so published notes are never quietly rewritten. This departs from it, knowingly: - the tag keeps pointing at a77db11, the commit the published jar was built from, and its CHANGELOG is left alone as the record of what was cut; - the published artifact does not carry the changelog at all — checked the jar on Central, it contains no `.md` — so nothing immutable disagrees with this; - the GitHub Release body is corrected the same way, which is where the convention already sends corrections. So the two surfaces a reader actually looks at agree with each other and with the rest of the family, and the tag remains the historical record. Re-establishing byte-exactness would mean moving the tag off the commit the artifact was built from, which is a worse trade. The finalize step that renames `[Unreleased]` is what let this through: it renames a heading and asks nothing about whether the subsections mean anything for a first release. cs-sdk shipped its whole Keep-a-Changelog skeleton the same way. Worth a check in that step. --- CHANGELOG.md | 32 +------------------------------- 1 file changed, 1 insertion(+), 31 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2112929..a8c4520 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,36 +7,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] -### Added +## [0.1.0] - 2026-09-07 - Initial release. - -### Changed - -- Identifier handling now preserves issuer and resource identity. Issuers are stored and compared - byte-for-byte (RFC 8414 §3.3) with no trailing-slash reconciliation; the terminating slash is - stripped only when *deriving* a `.well-known` discovery URL (RFC 8414/9728 §3.1). The resource - identifier is likewise preserved verbatim: deriving the Protected Resource Metadata path now - strips the terminating slash of the resource path (`/mcp/` → - `/.well-known/oauth-protected-resource/mcp`, RFC 9728 §3.1) without altering the resource - identifier itself. - - **Migration:** If your configured issuer differs from your authorization server's actual - identifier by a trailing slash, correct the config — the SDK no longer silently reconciles them. - -### Fixed - -- Deriving a Protected Resource Metadata URL now requires the resource identifier to carry a - scheme. A scheme-relative reference such as `//api.example.com/mcp` is neither opaque nor - authority-less, so it cleared the derivation gate and produced - `null://api.example.com/.well-known/oauth-protected-resource/mcp` — a URL the SDK then published - in the `resource_metadata` parameter of the 401 `WWW-Authenticate` challenge, where no client - could resolve it. Such an identifier is now rejected at derivation, naming the missing - component. RFC 8707 §2 requires an absolute URI, which RFC 3986 §4.3 defines as always carrying - a scheme, so no valid identifier is affected. -- The derived Protected Resource Metadata URL now carries the resource identifier's authority - verbatim. It was built from `URI.getAuthority()`, which percent-decodes, so an identifier whose - userinfo contained an encoded `@` (`https://u%40b@api.example.com/mcp`) derived - `https://u@b@api.example.com/…` — an authority with two `@` delimiters where the identifier - names one. The raw authority is now used, matching the derived path, which already preserved - its percent-encoded octets.