-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Breaking change from v2.0.0 to v2.1.0 #938
Comments
FWIW semver is flawed in nearly every case, even many things deemed as non-public API are implicitly public. Removal of a bug is often implicitly a backwards incompatible change, your program may be relying on the previous behaviour. This situation is a bummer maybe, but you should always pin versions. |
we dropped support in for < 7.6 in the changelog in 2.0.1 but not in the package.json. how is it breaking, exactly? is npm not allowing you to shrinkwrap? if so, that would be an acceptable reason to drop the node version restriction. |
if Koa doesn't adhere to semantic versioning then fine, I will pin my dependency to a specific version and check manually for safe updates from time to time. At least now i know. Cheers! |
It's basically impossible to truly adhere to semver. Function signatures etc are not the only thing that make up a program, and subtle things change all the time, what errors might be throw, where they're thrown, bugs that are fixed and change behaviour etc. These things are arguably not public API, but implicitly they are. TL;DR always pin. |
I don't think this is a breaking change as @jonathanong said, we already dropped support for node < 7.6 in document, even if koa core support node < 7.6, but it is hard to maintain middleware like session written with pure promise, and we can't make the ecosystem to don't use async await even it is native with node >=7.6. |
It seems 2.1.0 is a bugfix of node engine in package.json rather than breaking feature. It should only support Node>=7.6 in koa2, otherwise you can use koa1. |
i'm fine with the recommendation to pin the koa version (I have already done that) but i'm surprised to read a few comments questioning whether 2.1 was a breaking release. Maybe it's because i wrote v2.0.1 in the issue title instead of v2.0.0 (the last version to advertise node v4 support). koa v2.0.0 and v2.0.1 both ran fine in node v4 and v5 without issue, this script works fine: const Koa = require('koa')
const koa = new Koa() However, install koa v2.1.0 and run the same script in node v4 or 5:
This is a breaking change and a semver violation between koa 2.0.1 and 2.1.0. My app (which depends on koa@^2.0.0) broke overnight for many node 4 and 5 users. I just wanted to post this extra detail to clear up any confusion. |
So, I think the main issue was/is that Koa v2.0.0 should never have been used/released. Alpha tagged releases came after Koa v2.0.0, it was never a stable or public release anyway (AFAIK). We run Koa v2.0.0-alpha.7 in production and shrinkwrap (which is the sane way to control dependencies anyway), we had no issues with the Koa v2.1 release, though we also wait for node v8 LTS before jumping. It was however foreseeable that users with dependency on |
Hello guys, How can i use await Promise.all for my function? Thanks. |
This project seems cursed with semver and npm tagging misuse.
Koa v2.0.1 supported node v4 and above. However, Koa v2.1.0 does not support node v4 and 5. Therefore, koa v2.1.0 introduced a breaking change and should have been released as koa v3.0.0.
My app (which depends on koa@^2.0.0) started breaking overnight on node v4 and v5 (after koa v2.1.0 was released) - obviously this should never happen where semantic versioning is adhered to.
The text was updated successfully, but these errors were encountered: