fix: address @octokit/rest deprecations
#249
Conversation
I'm confused I don't understand why the tests are failing, I'll have to digg some more into it |
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
|
All right, this one is ready |
58184ac to
72970f4
Compare
Can you squash your commits before merging (as in don't split changes between The goal is to have atomic commits, so in the future when we look at the git history we know what goes with what. That also prevent mistakes in case we have to rollback a change. With atomic commits we can rollback any one commit without have to worry about forgetting to also rollback another one. |
|
I usually split them out so I have a test commit that has failing CI and then a fix/feature commit that is green, to make sure that the test is actually doing what it is supposed to do. In this case I had to If you like we can enforce squash merging for the semantic-release repos. Other than that, is this good to merge? |
|
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