1. 9

  2. 2

    This is a great list of ways that API changes can break things, and is super valuable.

    I really really really wish that everyone would look at the Django strategy for this though. So many times the issues that appeared were of the “we introduced more functionality, and made it be the way it worked in the same release”. Offering new functionality as an opt-in in one release, then making it the new default in another, is such a nicer way to move forward. As a benefit, it gives you a release where people are testing this and you can catch issues in your own implementations!

    “We shipped HTTP/2 and also enabled it by default in a release, offering opt-out” vs “we shipped HTTP/2 as an opt-in, so people could upgrade to the new release no matter what, and then roll out upgrades to just this, then opt-in’d in the next release” is such a big difference in ease of rollout IMO.

    It feels equivalent, but when you consider releases bundle so many things together, having nice and long on ramps is very helpful. I do think Go’s GODEBUG strategy is generally quite nice though, so they deserve credit there IMO.

    1. 2

      I’ve tried both releasing with opt-in and opt-out. The vast majority just don’t opt-in to the change and hit the problems one release later when it becomes default. And you get more projects started with the default that is going to be deprecated.