Problem
PackageDetailsVersionHistoryItem.RefreshChangeLog resolves the text it renders through
UpmCache.GetBestMatchPackageInfo(name, productId, isInstalled, versionString). That call falls
back to the best available PackageInfo when the editor has not fetched per-version metadata for
the version whose row is expanded.
Measured against a local registry serving two versions, each with its own _upm.changelog:
version 1.1.0 infoVersion=1.1.0 changelog=[### Changed\n- Newer probe entry for 1.1.0.]
version 1.0.0 infoVersion=1.1.0 changelog=[### Changed\n- Newer probe entry for 1.1.0.]
So expanding an older version can show the newer version's notes. #402 makes the INSTALLED
version exact (that is what #362 asked for) by shipping _upm.changelog in package.json, which
the editor reads from the resolved package on disk.
What the remaining case needs
Per-version accuracy for versions the user has NOT installed -- the "what changed in the update I
have not taken yet" case -- requires _upm.changelog in the REGISTRY document for each version.
Two independent blockers, both measured in #402:
npm publish deletes every _-prefixed key from the metadata it uploads
(@npmcli/package-json's _attributes normalize step; prepareSteps and pacote.manifest
both include it, and there is no opt-out). libnpmpublish called directly preserves the field,
but release.yml authenticates through npm OIDC trusted publishing, which lives in the npm
CLI, so bypassing the CLI means reimplementing that exchange on the irreversible publish step.
- OpenUPM -- the recommended install path -- republishes from the Git tag through its own
npm-CLI pipeline, so it would strip the field again regardless of what we upload.
Acceptance criteria
- Expanding a non-installed version in Version History shows that version's own notes.
- No change to the irreversible publish step that is not covered by a rehearsal against a real
registry.
Notes
Blocked upstream as written. Worth reopening only if a user asks for pre-update notes, or if npm
gains a way to publish Unity's documented _upm metadata. The full trace, the reproduction
snippet, and every measurement are in
.llm/skills/changelog-management/references/upm-changelog-surface.md.
Problem
PackageDetailsVersionHistoryItem.RefreshChangeLogresolves the text it renders throughUpmCache.GetBestMatchPackageInfo(name, productId, isInstalled, versionString). That call fallsback to the best available
PackageInfowhen the editor has not fetched per-version metadata forthe version whose row is expanded.
Measured against a local registry serving two versions, each with its own
_upm.changelog:So expanding an older version can show the newer version's notes. #402 makes the INSTALLED
version exact (that is what #362 asked for) by shipping
_upm.changeloginpackage.json, whichthe editor reads from the resolved package on disk.
What the remaining case needs
Per-version accuracy for versions the user has NOT installed -- the "what changed in the update I
have not taken yet" case -- requires
_upm.changelogin the REGISTRY document for each version.Two independent blockers, both measured in #402:
npm publishdeletes every_-prefixed key from the metadata it uploads(
@npmcli/package-json's_attributesnormalize step;prepareStepsandpacote.manifestboth include it, and there is no opt-out).
libnpmpublishcalled directly preserves the field,but
release.ymlauthenticates through npm OIDC trusted publishing, which lives in the npmCLI, so bypassing the CLI means reimplementing that exchange on the irreversible publish step.
npm-CLI pipeline, so it would strip the field again regardless of what we upload.
Acceptance criteria
registry.
Notes
Blocked upstream as written. Worth reopening only if a user asks for pre-update notes, or if npm
gains a way to publish Unity's documented
_upmmetadata. The full trace, the reproductionsnippet, and every measurement are in
.llm/skills/changelog-management/references/upm-changelog-surface.md.