Breaking Bad - Breaking API Compatibility

When is breaking something not a bad thing?

  1. When it's done with purpose.

  2. When the result is better than the original.

So, if you know you have broken something, and that means it's broken for everyone, why stop with just the currently required change? Why not fix everything that was wrong in the first place?

If an API was bad, and you had to make a small breaking change in order to resolve some limitation, isn't it time to solve most, if not all that was bad?

Ok, so you may not know all the ways that it might go from bad to good right then, but it's probably the best time to re-consider just what that might be while it's busted.

Broken APIs are the greatest opportunities for improvement.

Make sure you take advantage!

Knowing when you've broken API compatibility is therefore very important as well. Liferay's new baseline capability is exactly intended to make this very clear, as quickly as possible, at build time.

Blogs
Thanks for this empowering philosophy, besides your fantastic code explanations these fundamentals and thoughts are a best practice for everyone.
You are totally right.
In particular I agree with "Broken APIs are the greatest opportunities for improvement."
Hey, why not take this great opportunity to overhaul the broken RPC API?
You know what I mean: all those dozens of method in com.liferay.portal.service.http.xyzServiceHttp classes (and of course in com.liferay.portlet.xyz.service.http too) that use not serializable java.io.InputStreams as parameters.
Calling any of them immediately throws a java.io.NotSerializableException, thus rendering this API rather useless.
Sorry to bother you with such mundane stuff, but doesn't philosophy always ask for palpable action?