chore(main): release 0.2.0

[tschneidereit]

🤖 I have created a release beep boop

0.2.0 (2025-08-29)

Features

• crypto: add support for PKCS#8 key import (#251) (059d09a)
• dx: add default message for missing handler (#264) (58b6042)
• implement AbortController and AbortSignal (#240) (215b1d9)

---

This PR was generated with Release Please. See documentation.

[tschneidereit]

@andreiltd looks like the permissions are sorted out now. However, IIRC we weren't intending to call this release 1.0.0, right?

[andreiltd]

Nice! Yeah, I think we need to start with some release and the bot will pick it up from there. If you see the previous PR commit message it includes footer: Release-As: . This is where you can override whatever default is.

[tschneidereit]

Nice! Yeah, I think we need to start with some release and the bot will pick it up from there. If you see the previous PR commit message it includes footer: Release-As: . This is where you can override whatever default is.

Ah, okay. Would it be okay if I hand this back to you at this point? I'd like to focus on getting the SpiderMonkey update completed.

[andreiltd]

Sure! What I would do is to close this PR, delete the branch and then push an empty commit to main, something like:

git commit --allow-empty -m "chore: prepare for release 0.2.0" -m "Release-As: 0.2.0"

Which should create a release PR again but using 0.2.0 this time. Does that sound OK?

[tschneidereit]

Sounds good to me, though you might need to do this via a PR, since we don't allow pushes to main directly

[tschneidereit]

Though maybe we can also just edit things here? I think we should update the release notes anyway to describe how this is the first release in this repo, but how there have been releases via ComponentizeJS

[andreiltd]

Though maybe we can also just edit things here?

I can try but I don't know if this would work. I couldn't find any docs that would explain if it's OK to manually edit the release PR.

EDIT: I can also try to test this on the fork, although so far it wasn't the most reliable approach. 😅

I think we should update the release notes anyway to describe how this is the first release in this repo, but how there have been releases via ComponentizeJS

It's possible to edit release notes after the release, isn't?

[tschneidereit]

I can try but I don't know if this would work. I couldn't find any docs that would explain if it's OK to manually edit the release PR.

Hmm yeah, no idea. I wonder if we'd be best off doing the first release manually, with hand-written release notes?

It's possible to edit release notes after the release, isn't?

It is, but that wouldn't include the changelog itself, just the release notes in the UI.

[andreiltd]

OK, so let's make the first release manually. The artifacts would be the source code only, right?

[tschneidereit]

I think that's okay for this first release, yes: we wouldn't expect anyone to use this release's binaries anyway. We can call it 0.1.0, and add a CHANGELOG.md as described above.

[andreiltd]

Here is the PR for changelog ,which I copied over from this PR: #259

As for the release notes I will initially just add:

While this is our initial release in this repository, StarlingMonkey build artifacts have been distributed as part of ComponentizJS releases for some time.

[tschneidereit]

@andreiltd looks like things worked, and the initial changelog is properly picked up. We can now do the 0.1.0 release manually and then get a new release-please release going

[andreiltd]

Should I just copy the changelog content to release notes for 0.1.0?

[tschneidereit]

That sounds good to me, yes

[andreiltd]

I think we need some commit to land in main for this to be updated?

[tschneidereit]

@andreiltd maybe land either or both of #240 and #251? Would be great to have those in!

[andreiltd]

I think this works as expected!

[andreiltd]

Hey @tschneidereit, I thought we would merge this before ff140 so that we have a release with weval artifacts but that's not too important. I think that before landing the release PR we will have to remove weval artifacts from release script, right?

https://github.com/bytecodealliance/StarlingMonkey/blob/main/.github/workflows/release-please.yml#L60C1-L72C67

[tschneidereit]

@andreiltd oh, my bad :( I hadn't considered that the 0.1.0 release doesn't have artifacts added to it, I'm sorry.

We can in theory manually upload them, but it's unclear if we have someone actively asking for them.

Agreed on the weval artifacts, those should be removed. Would you be up for doing that, or should I?

[andreiltd]

No worries! Here is the PR to deweval artifacts: #261

[andreiltd]

Hey @tschneidereit, shlould we merge this? It will hopefully create gh release and uploads artifacts when it lands on main. 🤞

[tschneidereit]

@andreiltd yes, we should! Since I'm marked as the author, it requires you to r+ it first, though. (I could override that, but don't see a good reason to.)

[github-actions]

🤖 Created releases:

• v0.2.0

🌻