Release v2.3.0

[Siegrift]

Rationale

I couldn't push directly to main as written in the release instructions so I'm opening a branch instead. We should also do a GH release afterwards.

The PR should be merged using rebase and merge strategy so the commit hash is not changed.

[dcroote]

I initially couldn't tell if this commit was tagged as v2.3.0 or not from the PR, then confirmed it was by going directly to tags and matching the commit SHA with the tag SHA.

I see you didn't have a problem with the 2.3.0 npm release so I agree with #119 that the GitHub-related instructions should be updated.

[dcroote]

Ugh. The commit SHA changed despite me using "Rebase and Merge". Per GitHub's docs apparently this is expected:

Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

So I went ahead and deleted the tag (which belonged to a commit that was no longer part of the repo after the branch was auto-deleted) and tagged the latest commit, 7d00c0a.

[Siegrift]

Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

Oh, that's a pity. I assumed if the author of the PR merges it then the metadata stays the same (I knew that when someone else merges a PR he is added as co-author so the metadata changes). I can see only two workarounds:

• Use merge commits (I dislike this)
• Change the tag manually after merge (I dislike this as well)

[dcroote]

I agree neither is ideal (went with change tag manually for this since it was already merged). Though there is an option 3- have push access to main 😄

[bbenligiray]

I added @Siegrift to the Airnode releasers team