5 ms·

I'll start from bottom options: 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go.

I'll start from bottom options: 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) 1) "there are a lot of google results with solutions that the new breaking changes will make obsolete" - that's what semver and major versions are for. "We'll break Stack Overflow answers" doesn't feel like a valid reason. jQuery has had its fair share of breaking changes in the last 12 years, and we know the numbers if we compare `jQuery` vs `request` questions on Google/Stack Overflow, so again, it doesn't feel like a valid reason.

codetrotter 8y ago
> 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have to start from zero — it can start from where the old package left off. In terms of version control history it could even start life as a copy of the old git repo. The developers having worked on the old version for that long certainly know what will be best for them I should hope. Whether that means reworking the old code for the new package, or taking some parts of it with them, or rewriting everything. As long as they don’t fall for the temptation of implementing new features in the rewrite, or at least not any significant number of new features. > 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) Just because people are using it doesn’t automatically mean people enjoy using it.
Klathmon 8y ago
As another commenter answered 3 and 2 (and I agree with them), i'll answer 1: There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major version of react-router, or various other examples of this that come back around and bite people. The only difference with those is that they don't have literally 10 years of documentation, blogs, SO answers, and more with no version numbers on them. This isn't an instance where dogmatic application of the "rules" is a good idea. This is one where choosing to make a new library under a new name is the lesser of 2 evils. The hope is it will cause less problems, less confusion, less difficulty for both new and old devs, and be better for everyone. I don't know about you, but i've absolutely spent ~30 minutes on multiple occasions trying to figure out why some documentation seems to be wrong, or a feature isn't working in a library only to realize that i'm not on the latest version or the docs don't have an easy way to go back through old versions, and it's a big timewaste as well as a source of bugs. This move is trying to prevent that!
- Izkata 8y ago
  > There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Doesn't this library also predate the semver spec, and wasn't just such major alterations the purpose of the major version number back then?

codetrotter 8y ago

> 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have to start from zero — it can start from where the old package left off. In terms of version control history it could even start life as a copy of the old git repo. The developers having worked on the old version for that long certainly know what will be best for them I should hope. Whether that means reworking the old code for the new package, or taking some parts of it with them, or rewriting everything. As long as they don’t fall for the temptation of implementing new features in the rewrite, or at least not any significant number of new features. > 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) Just because people are using it doesn’t automatically mean people enjoy using it.

Klathmon 8y ago

As another commenter answered 3 and 2 (and I agree with them), i'll answer 1: There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major version of react-router, or various other examples of this that come back around and bite people. The only difference with those is that they don't have literally 10 years of documentation, blogs, SO answers, and more with no version numbers on them. This isn't an instance where dogmatic application of the "rules" is a good idea. This is one where choosing to make a new library under a new name is the lesser of 2 evils. The hope is it will cause less problems, less confusion, less difficulty for both new and old devs, and be better for everyone. I don't know about you, but i've absolutely spent ~30 minutes on multiple occasions trying to figure out why some documentation seems to be wrong, or a feature isn't working in a library only to realize that i'm not on the latest version or the docs don't have an easy way to go back through old versions, and it's a big timewaste as well as a source of bugs. This move is trying to prevent that!

Izkata 8y ago
> There's a difference between "has some breaking changes" and "will have basically an entirely new API, and will support different features and make different tradeoffs" Doesn't this library also predate the semver spec, and wasn't just such major alterations the purpose of the major version number back then?