The typical libv8-node release process (that I should document) is:
merge whatever PRs are wanted for a release into node-X (here node-16)
wait for last merge commit CI to be green
do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
wait for CI to be green (it should given the changeset, but sometimes silly mistakes happen!)
tag that release commit vX.Y.Z.W
create a release from the tag on the GH page, and attach the CI artifacts of the release commit
push the CI artifact gems to rubygems
(Most of these can be automated via GH workflows, e.g tag => create GH release + attack artifacts + push to rubygems†. or it can be a manual GH "dispatch workflow")
† this one can also both require and wait for 2FA with some interesting techniques
The degraded libv8-node release process is the same, except (when CI is broken because reasons outside of release blockers):
merge whatever PRs are wanted for a release into node-X (here node-16)
wait for last merge commit CI to be as green as possible
do a Release X.Y.Z.W commit on the branch (like so). It should update changelogs and whatever too.
build x86_64-{darwin,linux,linux-musl} gems on an Intel machine (resp. make test, make test/linux, make test/linux-musl)
build arm64-darwin and aarch64-{linux,linux-musl}gems on an Intel machine (resp.make test, make test/linux, make test/linux-musl`)
build ruby platform gem with rake build
tag that release commit vX.Y.Z.W
create a release from the tag on the GH page, and attach the artifacts of the release commit
@SamSaffron since mini_racer version constraint on
libv8-nodeis~> 16.10.0.0and this is clearly a bug fix, there is nothing to be done for node-16 on the mini_racer side, only pushing the new node 16 gems.The typical libv8-node release process (that I should document) is:
Release X.Y.Z.Wcommit on the branch (like so). It should update changelogs and whatever too.vX.Y.Z.W(Most of these can be automated via GH workflows, e.g tag => create GH release + attack artifacts + push to rubygems†. or it can be a manual GH "dispatch workflow")
† this one can also both require and wait for 2FA with some interesting techniques
The degraded libv8-node release process is the same, except (when CI is broken because reasons outside of release blockers):
Release X.Y.Z.Wcommit on the branch (like so). It should update changelogs and whatever too.x86_64-{darwin,linux,linux-musl}gems on an Intel machine (resp.make test, make test/linux, make test/linux-musl)arm64-darwinand aarch64-{linux,linux-musl}gems on an Intel machine (resp.make test, make test/linux, make test/linux-musl`)rubyplatform gem withrake buildvX.Y.Z.WOriginally posted by @lloeki in https://github.com/rubyjs/libv8-node/issues/37#issuecomment-1400140464