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.

Sign up for GitHub

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

Jump to bottom

Drop support for Node 8; test in Node 13 #1871

Closed
paulmelnikow opened this issue Feb 7, 2020 · 11 comments
Closed

Drop support for Node 8; test in Node 13 #1871

paulmelnikow opened this issue Feb 7, 2020 · 11 comments
Labels
released on @beta

Comments

@paulmelnikow
Copy link
Member

Node 8 hit end of life on 12/31 so it's time to drop support for it.

That's a breaking change for Nock and normally I like to batch up the breaking changes to avoid super-frequent semver major bumps. There are a few TODOS marked TODO-12.x which I'd like to push through at the same time.

We could merge some of these on the beta branch. Should we force push master to beta and then start pushing this work through?

The last time we released from the beta branch, we ended up needing to rewrite history on the commits when they were released (beta is currently on c0be8f8 which is 235 commits ahead and 334 commits behind master). I want to try to avoid that this time, if we can!
@paulmelnikow paulmelnikow mentioned this issue Feb 7, 2020
Merged
paulmelnikow added a commit that referenced this issue Feb 7, 2020
@paulmelnikow
Temporarily disable Node 8 CI to unblock release
1606b41 
CI is broken for Node 8. We're dealing with updating the CI this in #1870 and it should be fixed shortly. I'm removing this for now, so we can get the patch for #1836 shipped.

We should also prioritize #1871 so we don't accidentally ship a breaking change for Node 8.
paulmelnikow added a commit that referenced this issue Feb 7, 2020
@paulmelnikow
Temporarily disable Node 8 CI to unblock release
3996511 
CI is broken for Node 8 beacuse semantic-release won't install. This isn't just breaking all the builds, it's also blocking release.

We're dealing with updating the CI this in #1870 and maybe we'll be able to fix this. If not, we should also prioritize #1871 so we don't accidentally ship a breaking change for Node 8.

I'm removing this for now, so we can get the patch for #1836 shipped.
@paulmelnikow paulmelnikow mentioned this issue Feb 7, 2020
Closed
@weekly-digest weekly-digest bot mentioned this issue Feb 9, 2020
Closed
This was referenced Feb 10, 2020
Merged
Merged
@paulmelnikow
Copy link
Member Author

paulmelnikow commented Feb 10, 2020 •
edited

I'm thinking I will force push current master to the beta branch, and then start merging commits. When it's time to release, maybe we can open a new PR to merge beta into master?

@gr2m are you able to weigh in on this?

Added: Maybe it's also a good idea to save the current (11.0) beta branch in case we ever need to refer to it.

@gr2m
Copy link
Member

gr2m commented Feb 10, 2020

I'm thinking I will force push current master to the beta branch, and then start merging commits

👍

When it's time to release, maybe we can open a new PR to merge beta into master?

if configured correctly, semantic-release will publish from the beta branch, too. Let me quickly have a look at that before you get started on beta, ok?

@gr2m gr2m mentioned this issue Feb 10, 2020
Merged
@gr2m
Copy link
Member

gr2m commented Feb 10, 2020

It actually already is configured correctly, but I moved it to actions anyway: #1892

@gr2m
Copy link
Member

gr2m commented Feb 10, 2020

It's important to not git push --force to beta. Changes in master while working on beta need to be merged instead, in order to persist commit history. semantic-release is now using git notes attached to commits to keep track of releases. If we need to rebase for some reason, I can do it manually and re-attache the notes again. See https://github.com/semantic-release/semantic-release/blob/804fc2a943945ac77c79dfd9b13301feeda27c60/docs/support/troubleshooting.md#release-not-found-release-branch-after-git-push---force

@paulmelnikow
Copy link
Member Author

How do we get beta into a usable starting point?

@gr2m
Copy link
Member

gr2m commented Feb 10, 2020

An initial git push --force base on latest master is fine, it won't destroy any history. The new beta has nothing todo with the old beta. Ideally we would delete the beta branch once we merge a PR from beta into master

@paulmelnikow
Copy link
Member Author

Thanks for explaining that!

@paulmelnikow paulmelnikow mentioned this issue Feb 11, 2020
Merged
@paulmelnikow
Copy link
Member Author

This was done in #1895. I'm not sure why it didn't close it.

@gr2m
Copy link
Member

gr2m commented Feb 11, 2020

The close #XYZ will only be applied once the commits are merged into the repositories main branch.

@github-actions
Copy link

🎉 This issue has been resolved in version 11.9.0-beta.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

@paulmelnikow
Copy link
Member Author

The close #XYZ will only be applied once the commits are merged into the repositories main branch.

Ahhh I guess before we had beta as the main branch.

@paulmelnikow paulmelnikow mentioned this issue Feb 12, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
released on @beta
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gr2m @paulmelnikow