3 ms·

If you are making a new API that cannot serve the needs of older users, then you are basically saying to your old users that you would rather they leave. At th

by taeric 2y ago

If you are making a new API that cannot serve the needs of older users, then you are basically saying to your old users that you would rather they leave. At the least, you are signalling that you are inclined to give them more work. Don't be surprised when they decide that their migration isn't from your old service to your new one, but from your old service to a competitor. Note that this is not the same as saying, "if you want to use the new features, you have to do the work to tell us more about what you are doing by using the new api." More, you can have some restrictions. But, at large, the view you are espousing reminds me of the blog by Yegge about Google's deprecation policy. (Link: https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc https://steve-yegge.medium.com/dear-google-cloud-your-deprec...). I'm sympathetic to the idea that some APIs are terrible and are best redone. I have seen far too many redone APIs that do not service existing user's needs and that resolve into a complete disaster. In almost all cases, it is because the team doing the work thought that it was best to offload all thoughts of how to migrate onto every other team that was calling to them. You think it would be a lot of work to make a facade/proxy/whatever you want to call it layer. You aren't wrong. But largely what you have done is shifted that work to every single caller you have.

n4r9 2y ago
It depends... let's say you're the leading product in the area, your users are devs, and there's a good reason behind the change, then you're probably okay to deprecate APIs. For example, NUnit has now deprecated the "Assert.AreEqual" method: https://docs.nunit.org/articles/nunit/writing-tests/assertions/assertions.html https://docs.nunit.org/articles/nunit/writing-tests/assertio... . For me this meant running through hundreds of tests and rewriting them using "Assert.That" or sometimes using "ClassicAssert.AreEqual". I guess I see it as part of the job of being in an evolving industry.
- taeric 2y ago
  Library deprecations are fairly different from service deprecations. That said, same points generally stand. I know MANY people that no longer use Guava because they got tired of how rapidly they had to update their code due to changes in the library. Similarly, I know very few people that have gotten upset with the deprecation policy of Java core.

by taeric 2y ago

n4r9 2y ago

It depends... let's say you're the leading product in the area, your users are devs, and there's a good reason behind the change, then you're probably okay to deprecate APIs. For example, NUnit has now deprecated the "Assert.AreEqual" method: https://docs.nunit.org/articles/nunit/writing-tests/assertions/assertions.html https://docs.nunit.org/articles/nunit/writing-tests/assertio... . For me this meant running through hundreds of tests and rewriting them using "Assert.That" or sometimes using "ClassicAssert.AreEqual". I guess I see it as part of the job of being in an evolving industry.

taeric 2y ago
Library deprecations are fairly different from service deprecations. That said, same points generally stand. I know MANY people that no longer use Guava because they got tired of how rapidly they had to update their code due to changes in the library. Similarly, I know very few people that have gotten upset with the deprecation policy of Java core.