If there is one thing I wish I could take from Perl and give to the current hot languages, it's the importance of not breaking shit when you release new versions of stuff. If someone's code worked yesterday with your library, it should also work today after you add a new feature.
Yet, apparently, this is not the way we do code. We expect every developer to be so devoted to a random library that they keep track of all the breaking changes and are excited about them.
Please stop that.
@joelle I think that a challenge is that there are sometimes inherent trade-offs between improving the experience for new users or existing users. Sometimes, we want to break compatibility because we've learned and believe that a different design would be easier for new users. If we maintain compatibility, we're stuck with the results of prior decisions. If we break it, we externalize work on others.
But I think it's also reasonable to say that open source authors are not your supply chain :)
@jawnsy @joelle I think depreciation is the solution here. Introduce a new API and delicate the old. Will not be updated, but will compile for those who need whatever it did before.
It's helpful to know that I'm using the latest, best designed API available, but I still need old stuff to compile and run without changes and get the same old (possibly crappy) behaviour because some other code relied on that.
So, keep the old in place, and give us the new and shiny--we can do both!
@kdacar @joelle That's sometimes the solution, sure. But it's not always possible, and there's still a carrying cost for the deprecated approach (even if it's just some extra files in packages, though more likely there's at least some maintenance cost.)
API design and evolution is a tough thing. I think that one of the reasons early-stage projects and startups can be very fast is because they don't have many users/customers, so they can make frequent breaking changes.
Joelle
Jonathan Yu
kdacar