-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Consider Major Version Update For Breaking Changes #3468
Comments
The observed behavior is compatible with item 4 in the linked document. Any CI that treats |
This is a very naive way of thinking, declaring that the entire industry must conform to your specific way of versioning your software. When the industry as a whole has created standards that state that Regardless of whether your project follows semvar practices or not, the platform that you publish you code on (npm) and the tooling the industry has build around JS package management does make general assumptions when it comes to package updating, specifically when it comes to how to version your software so you are not responsible for breaking other peoples code. Are you suggesting we notify npm and yarn and have them adjust the way they treat dependency versioning? As an aside, the particular change that was made here that swaps the parameter order or the |
I'm not. That's how they work since ever. They take a conservative approach for versions styled 0.x.y because that's how some projects used to operate in the early days of nodejs, including this one it seems. Think about it, a software versioned 0.x.y is quite expected to have breaking changes all the time, otherwise they could have gone with 1.x.y. Some CI tooling would also propose semver-major updates, so I don't see what difference does it make were 0.28.x to 1.0.0.
I see a lot was discussed around this topic #2938 #3369. Introducing an export under a different name while deprecating the older one could be a better approach to avoid breaking changes. I think avoiding a breaking change is more valuable than going for it while declaring it a breaking change with a major version. |
I wasn't aware that npm or yarn treated 0.x.y packages differently. I know it's been discussed many times before in previous issues, but is there an update on the reason ramda doesn't want to move to a 1.x.x version? It's been around for quite a while now and has quite high adoption. I personally think the 0.x.y days might be behind you. Not just for jumping on the semantic versioning wagon, but to declare that this library is beyond experimentation and ready for some stable releases. |
There is no strong reason. We have had many discussions over the years about what should get done before 1.0.0. I'm of the mind we should just go for it. I will continue to discuss it with @Harris-Miller and I believe it will get done soon, say in the next month or three. |
Awesome, love that. I'll keep my eyes out for the possible change. |
Hi,
I saw a similar thread here, but wanted to bring this issue up to stand on its own. My team and I spend quite a while debugging an obscure issue in our lower environments, to eventually track it down to the parameter order swap in
propEq
during the 0.28 to the 0.29 release.Like the linked thread mentioned, our CI process (and I would wager most others out there) auto increment packages for patch and minor version changes. Please consider updating your versioning to match semvar practices to prevent issues like this in the future.
I've written a LOT of code at previous companies using
propEq
and I can only imagine the fires happening over there.The text was updated successfully, but these errors were encountered: