-
Notifications
You must be signed in to change notification settings - Fork 166
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
Ubuntu non-LTS strategy #967
Comments
I've gone ahead and swapped 16.10 for 17.10. |
+1 on the strategy of maintaining coverage of the latest non-LTS build, and all their supported LTS builds. |
Make sense to me, latest non LTS + LTS supported version. |
Has 17.10 been deployed yet? I can reliably trigger a kernel lockup from cctest with the x86_64 4.13 kernel (both -generic and -lowlatency) that has been fixed in the mainline 4.13.11 kernel. |
@bnoordhuis yes, we've had 17.10 in the node-test-commit-linux mix for a week now, green and looking OK.
|
@nodejs/build discussed in last meeting. No objections. |
Renewed issue for 2019 - #1668 |
We're a bit behind on Ubuntu. We have solid coverage of LTS and we have 16.10 in the mix too.
16.10 was EOL in July and I'd like to remove it to free up resources. Since we have 16.04 in the mix I think we can afford to ditch Ubuntu non-LTS more freely than we're agreeing with Fedora (@ #962) which doesn't do LTS.
After freeing up 16.10, I'd like to add 17.10 in their place. This would skip 17.04 but it's EOL in January anyway so IMO we've missed that boat.
18.04 will be LTS so we'll hang on to that one longer obviously. Then by the time we get to 18.10 we could replace the 17.10 (EOL in July) machines with it.
Thoughts on Ubuntu non-LTS strategy?
The text was updated successfully, but these errors were encountered: