Consider Major Version Update For Breaking Changes
BradStell opened this issue · comments
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.
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.
The observed behavior is compatible with item 4 in the linked document. Any CI that treats x increments in 0.x.y as anything other than a major bump needs to be fixed. Also not all packages follow semver anyways. Single package upgrades gated by end to end tests should make it doable to identify upgrade issues.
Any CI that treats x increments in 0.x.y as anything other than a major bump needs to be fixed
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 x is in fact a minor update and not a major one.
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 propEq function goes against ramda's design philosophy of "data last". This function is now data first, and cannot be partially applied without first flipping the parameter order. The propEq function should be renamed to eqProp be more semantically inline with the change.
Are you suggesting we notify npm and yarn and have them adjust the way they treat dependency versioning?
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.
As an aside, the particular change that was made here that swaps the parameter order or the
propEqfunction goes against ramda's design philosophy of "data last". This function is now data first, and cannot be partially applied without first flipping the parameter order. ThepropEqfunction should be renamed toeqPropbe more semantically inline with the change.
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.
is there an update on the reason ramda doesn't want to move to a 1.x.x version?
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.