Release web-features 0.1.1

[foolip]

No description provided.

[foolip]

@ddbeck do you have preferences for how to publish to NPM? https://github.com/w3c/webref/blob/main/.github/workflows/release-package.yml has some stuff we can take inspiration from, but I haven't set this up before, curious if you have?

[foolip]

Also: https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages

[ddbeck]

I set up BCD's release workflow. It was and is a multi-step process:

1. Open a release PR (bump package.json, write release notes, etc.)
2. Merge the PR when it was time to release
3. Use the GitHub releases UI (originally with some copy-and-paste, later with a script generate a URL prefilling the fields) to actually trigger the publishing GitHub Actions workflow

It worked OK. Ultimately, what I wanted to build was a workflow much closer to webref's: open a PR and merge it to trigger a release. It was hard to glue together with all of the other tasks that had accreted around BCD's releases, so if we can do something like earlier it will probably be easier. Though looking at webref's script to generate PRs has me a little intimidated. That said, if I had a wishlist for a release workflow, it'd probably contain:

• Use PR merging to trigger publishing
• Have some @dependabot style commands for managing the release PR (e.g., to do things like rebase or apply npm version … changes to package.json)
• Allow pushing to the release PR (e.g., to tidy up release notes)

[foolip]

OK, so I think we need these bits then:

• A workflow that can be triggered by hand or on a schedule which compares what's changed, generates a basic changelog and bumps the version, as a PR
• No automatic merging of that PR, and it can be editing by a human to improve the changelog
• A push workflow which checks for a change in version and if so publishes to npm. This will be triggered by merging the above PRs

Unclear: Use GitHub releases or tags at all? They're not a necessary part of the setup.

[foolip]

@depandabot-style commands require having a custom GitHub app installed and reacting to events. I've built something like it in https://github.com/foolip/spec-test-bot and it's not a trivial setup, I wouldn't recommend it really :)

[ddbeck]

Use GitHub releases or tags at all? They're not a necessary part of the setup.

I like the idea of using GitHub releases, just because I'm somebody who often looks to the GitHub releases page for a project to figure out what's new. If we're generating everything else, I don't expect it'd be particularly complicated to create the tags and releases (I know it used to be harder, though the gh CLI and some of the actions steps are much more capable since I last attempted it), but I acknowledge it's nice to have, not need to have.

@depandabot-style commands require having a custom GitHub app installed and reacting to events

Ah, bummer. I thought it was possible to trigger GitHub Actions workflows on comment contents. Oh well. Again, something nice to do, but not strictly required.

[ddbeck]

@foolip I tried to capture this discussion and turn it into a to-do list with #11 (comment).

Do you want this release to happen without the automation? Or is it better to automate from the start?

[foolip]

@ddbeck I think getting releases going is probably the most important next step for web-features. If you want to take a stab at it, setting it up however you prefer, I'll be happy to review!

[foolip]

Closing in favor of #99.