-
Notifications
You must be signed in to change notification settings - Fork 139
fix: address @octokit/rest
deprecations
#249
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
Conversation
cb6c532
to
7e61d9a
Compare
Something very funky is going on. I'll continue looking into it tomorrow. It seems that the tests pass again without my other changes: #248 (comment) so there is no urgency |
7e61d9a
to
58184ac
Compare
58184ac
to
72970f4
Compare
During the PR phase we can do pretty much whatever we want in terms off commits. What's important is for the commits that ends up on We could enforce squash merging , but there might some rare cases were we open one PR and do two things. For example I happened to have PR that both increase the minimum node version and update something else. In that case I keep 2 commits, 1 for the Node upgrade, 1 for the other thing. Regarding the code changes, yes we can merge. Not sure if #250 is necessary though, we can upgrade to v17 once it's out of beta. |
In these cases I often times edit the release notes after the release
It was just me testing, I'm not planning on merging it until v17 stable is released |
@octokit/rest
deprecations@octokit/rest
deprecations
🎉 This PR is included in version 7.0.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
closes #248