Add missing json-rpc-{engine,middleware-stream} CHANGELOG tag diff links

[MajorLift]

Background

While migrating @metamask/json-rpc-engine and @metamask/json-rpc-middleware-stream into the core repo, some earlier release commits that were untagged in the original repo (and didn't have CHANGELOG entries) were skipped by the tag porting script. These were created manually after the fact, and now they need to be added to the CHANGELOG as well.

• Motivation: #1802 (comment)

Tasks

• Tag diff links need to be added to the CHANGELOG for these manually-added tags.
  • json-rpc-engine: @metamask/json-rpc-{engine,middleware-stream} - Create tags for release commits that were untagged in the pre-migration repo #2002 (comment)
  • json-rpc-middleware-stream: @metamask/json-rpc-{engine,middleware-stream} - Create tags for release commits that were untagged in the pre-migration repo #2002 (comment)
• Add empty CHANGELOG entries for these versions to satisfy auto-changelog validation.

References

• Closes @metamask/json-rpc-{engine,middleware-stream} - Create tags for release commits that were untagged in the pre-migration repo #2002

Changelog

N/A

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've highlighted breaking changes using the "BREAKING" category above as appropriate

[Gudahtt]

I might be missing something, but are these entries useful? I like that we have the tags now, but omitting these entries from the changelog might make sense given that we don't have any change entries to document

[mcmire]

I'm fine with this. It looks like, however, that there are also missing tags for:

• 2.2.0: 286c271
• 2.1.0: 93e2b72
• 2.0.0: 4909d7f
• 1.0.0: 304f6ef

Dismissing review given Mark's comment. I also ran changelog:validate and it looks like we can just link 5.2.0 directly to the tag instead of a diff.

[MajorLift]

@Gudahtt autochange-log validation requires that version headings be present in the CHANGELOG for all of the versions in the tag diff links.

I think the tags and tag diff links are definitely adding useful information and shouldn't be removed. Given that, to get rid of the placeholder version headings, I think we'll have to either remove the logic for matching tag diff links with version headings, or add an option to specify a range (or ranges) of versions that we should expect to have empty changelogs because they were never written.

[MajorLift]

@mcmire Thanks for finding those commits! I added tags + diff links for those in 13ce5ad, and also found more early tags in json-rpc-middleware-stream.

[MajorLift]

I think just keeping the empty version headings might be useful, as they represent the full version history of the package, and the unwritten changelogs is also part of that history.

[Gudahtt]

We already don't have complete history of packages in our changelogs, as we didn't preserve changelogs from before we migrated metamask-controller to the core monorepo. Personally I'd look in at the tags in the repo if I wanted to dig into older releases, I would never look at the changelog for that. As such I wouldn't find these links useful. It's easy to navigate to the compare pages in GitHub if you know the tags.

I look at changelogs for additional high-level context about what each release consisted of, which is missing here.

[MajorLift]

In that case, seems like the way forward for package migrations would be: a) create the tags for untagged pre-migration releases, but b) not add them to the changelog?

I'm good with that so long as we can expect potential users of the package to look at the changelog as just a high-level overview of version history, instead of an exhaustive source of truth.

Although, it does seem like the empty-changelog tag diff links are equally as useful (or un-useful) as the existing tag diff links. Would it be worth modifying autochange-log so we can avoid potentially confusing users with a partial version history here (without having to add the empty version headings)? Of course, we can always get the complete version history from npm or git ls-remote --tags, so I guess the question is whether our expected audience for the changelog files is internal only or external users as well.

[MajorLift]

I'm good with just closing this PR. So long as the tags are created, I agree that the changes here aren't adding anything meaningful. We could always revisit this if there's confusion about the changelogs in the future. @Gudahtt @mcmire Would that be ok, or is there anything else you'd maybe like to address?

[Gudahtt]

Maybe we could leave a note about looking at the old archived repo to see the changelog for older releases? If you're concerned about this not being comprehensive, maybe that would be an effective way to fix that

[MajorLift]

The changelogs for these packages were created at json-rpc-engine@5.2.0 and json-rpc-middleware-stream@3.0.0, so all of the versions before that don't have any changelog entries anywhere.

No tag messages or tag diff links in the original repo, since these releases weren't tagged, and it seems no release commit messages, either.

The tag diff compare links we now have in core are our only window into what was changed in these early versions. Including them in the changelog would be nice, but preserving the original starting point for the changelog also makes sense to me.

[Gudahtt]

What I meant is that we could add this as a change entry:

### Changed
- See here for details: https://github.com/MetaMask/json-rpc-engine/blob/main/CHANGELOG.md

For json-rpc-engine for example

Either for every one of these blank releases, or once with a note about how it applies to all previous releases as well

Edit: Oh I'm sorry, I see, these entries don't exist.

[Gudahtt]

Given that these releases are ancient history and were never documented, closing this PR and leaving them undocumented would make sense to me.

[MajorLift]

Closing as WONTFIX