release: componentize-js v0.19.0

[jco-release-bot]

This is a release prep branch for componentize-js release v0.19.0.

To ensure this release is ready to be merged:

• Review updated CHANGELOG(s)

After this PR is merged tagging, artifact builds and releasing will run automatically.

[vados-cosmonic]

Much better, we've got the StarlingMonkey update change in there now :)

[tschneidereit]

I really dislike that release-please doesn't have any support for providing free-form release notes in the changelog or otherwise manually edit its output—Wasmtime's release process is much nicer in this regard. But oh well, it's not the end of the world.

[vados-cosmonic]

I really dislike that release-please doesn't have any support for providing free-form release notes in the changelog or otherwise manually edit its output—Wasmtime's release process is much nicer in this regard. But oh well, it's not the end of the world.

This is exactly why I don't use release-please! The release notes come together with a combination of git-cliff and properly created tags/etc:

https://github.com/bytecodealliance/ComponentizeJS/blob/main/cliff.toml
https://github.com/bytecodealliance/ComponentizeJS/blob/main/.github/workflows/release.yml#L271
https://github.com/bytecodealliance/ComponentizeJS/blob/main/.github/workflows/release.yml#L285

We retain full control of what the release notes look like and can build any automation we want around it!

I'm not sure exactly what you'd like to add but if you make an issue we can find some time to prioritize?

[tschneidereit]

Oh, my apologies! I completely mixed things up with the situation over in StarlingMonkey. Now I regret merging this already.

I'm not sure exactly what you'd like to add but if you make an issue we can find some time to prioritize?

Had I known that that works, I'd have made edits to the changelog to highlight some key aspects of the StarlingMonkey update. And generally I think it'd be nice if we'd pen a quick user-friendly summary of a release before the list of merged PRs. Given that it seems like we can, I don't think there's a need to change anything about the automation.

[vados-cosmonic]

Yeah so dynamic injection of sections in the generated release notes is a bit more complex as right now the notes are generated fresh according to the template, both at release-prep time and actual release time. There are at least two options:

1. If we wanted to influence what gets output in an automated manner we need probably a file in the repo or some dynamic pulling from the GitHub API (i.e. we could fish out a comment or some tagged portion of the PR description) to inject into the release notes.
2. If we wanted, we can modify the generated Changelog file then update the automation to reuse the changelog section instead of re-generating it when creating the GH release.

Best way to do either of these is probably by adding some more scripts that do the heavy lifting that we can call from CI.

[tschneidereit]

2. If we wanted, we can modify the generated Changelog file then update the automation to reuse the changelog section instead of re-generating it when creating the GH release.

That's exactly what I would like to be able to do: make edit suggestions during the review of the release PR, merge those edits, and have the result be used as the release's actual changelog.

[vados-cosmonic]

Yup, definitely doable then -- just matter of adding a script to extract the markdown from the existing CHANGELOG file that gets committed when a PR like this one merges!