Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v2.3.0 #118

Merged
merged 1 commit into from
Nov 28, 2023
Merged

Release v2.3.0 #118

merged 1 commit into from
Nov 28, 2023

Conversation

Siegrift
Copy link
Contributor

@Siegrift Siegrift commented Nov 27, 2023

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.

@Siegrift Siegrift self-assigned this Nov 27, 2023
Copy link
Contributor

@dcroote dcroote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 dcroote merged commit 7d00c0a into main Nov 28, 2023
3 checks passed
@dcroote dcroote deleted the release-2.3.0 branch November 28, 2023 05:12
@dcroote
Copy link
Contributor

dcroote commented Nov 28, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor

dcroote commented Nov 28, 2023

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
Copy link
Member

I added @Siegrift to the Airnode releasers team

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants