Release @webref/idl every Monday

[foolip]

Per w3c/browser-specs#252 (comment) it would be great to arrange to @webref/idl releases on Mondays.

@dontcallmedom @tidoust what would a process for this look like? If we have steps written down for how to do the release, could we take turns doing it, or even automate? Do you automatically publishing any other NPM packages?

[tidoust]

I don't have practical experience with automatically publishing NPM packages. My only worry with automating the release is that when there is a transient error with a spec, we may end up with a package that looks correct but e.g. where a partial interface definition is missing. In theory, we should be able to detect network failures. In practice, a (temporary) 200 OK response with an HTML document that is not the actual spec is not that uncommon...

Some notes on scheduling:

• Monday is when possible new specs get reported for inclusion in browser-specs. When a new spec gets added, we publish a new release of browser-specs.
• Updating browser-specs in Reffy is typically done through a PR that dependabot creates. Dependabot runs once per day, so PR usually gets created on Tuesday.
• Webref always uses the latest version of Reffy, so new specs will appear in webref within 6 hours of merging the PR.

Given the above, if we adopt a Monday release schedule, new specs will only make it to the @webref/idl package a week after they are introduced in browser-specs. A release on Wednesday or Thursday might be better... but then there are no guarantees that we'll have time to process browser-specs PRs by Wednesday in any case, so I'm not sure that optimizing release schedules really makes any sense!

[foolip]

Releasing on Thursday would actually be great and is what I originally wanted to suggest before w3c/browser-specs#252 (comment). This is because BCD is released every Thursday, and it makes sense to depend on BCD and @webref/idl together, which is what mdn-bcd-collector does. The update PRs for both should then come on Friday, which would be convenient.

If we don't both with automating releases for now, what steps should a human follow to determine if a release is warranted, and which part of the version should be bumped?

[tidoust]

Ideally, a semi-automated release process could be:

1. A job runs every Thursday and creates a PR that updates the version in packages/idl/package.json and details the expected diff in the body of the PR description. Default would probably be to increase the patch part of the version number. If the job fails, e.g. because a patch is no longer valid, it should rather create an issue.
2. One of us reviews the PR, checks the diff, checks the need to release a minor / major version instead.
3. When the PR is merged, another job reacts to the version increment in packages/idl/package.json, and creates the release and publishes the package.

I'm not sure to what extent lerna is needed with that approach. As far as I can tell, it would only take care of tagging the release and publishing the package, which may also be done with a couple of Git and npm commands.

[foolip]

@tidoust that sounds pretty good to me.

A non-trivial bit is creating a diff of the changes, since the previous state is only in an NPM package. Do we install a copy of the most recent package, and diff against that?

[foolip]

I discovered in #129 (comment) that publishing using npx lerna publish --force-publish no longer works when we have two packages, as both must then be updated, so I had to do it manually. So we'll have no use for Lerna at all I think.

[saschanaz]

Is there any remaining work item here?

[foolip]

No, this is done. Thanks @tidoust!