Breaking Backwards Compatibility: The easy way

Breaking Backwards Compatibility: The easy way

Say you have this piece of software that many people use. One day, you wake up and you have the urge to make them suffer. Well, there’s no better way to do so than breaking the software they’re using.

In this talk, I’ll walk you through very good ways to do so by showing examples taken from experience - because experience is the only thing that matters (TM) - so that you’ll be able, by the time this talk ends, to do the same to your users.

(P.S: If you’ve a kinder hearth, you can also do the exact opposite of what I’ll say and keep your users happy.)

C05edcc8a57f64b4e040d94ad89cee57?s=128

flaper87

April 19, 2015
Tweet

Transcript

  1. Breaking Backwards Compatibility

  2. Breaking Backwards Compatibility Easy Way

  3. None
  4. For attending Still here feel free to interrupt @flaper87 flavio@redhat.com

  5. Backwards Compatible... [...] If products designed for the new standard

    can receive, read, view or play older standards or formats, then the product is said to be backward-compatible[...] http://en.wikipedia.org/wiki/Backward_compatibility
  6. Don’t use versioning

  7. Don’t deprecate things

  8. Inconsistency FTW

  9. Assume you’re the user

  10. Keep everything public

  11. Keep users in the dark

  12. On a more serious note

  13. You’ve been that hacker

  14. Why Does it matter? It’ll help you save TIME but

    not only that. It’ll also help you save MONEY and it does not end there. It also helps saving KITTENS.
  15. Version Don’t re-invent it Cross-platform Cross-language Semver (?) Cap versions

  16. communicate Let them know what’s going away Do that at

    least 1 cycle in advance Have a well defined release cycle
  17. Consistent API Helps users migrating over new versions Helps you

    maintaining your software Design by contract
  18. Privacy Rules Private by default Don’t expose internals, commons or

    utilities If it’s public, you can’t assume it’s not being used
  19. Stability Attributes Stable shouldn’t break Unstable can break Be explicit

    about your software stability
  20. Testiing Unit and functional tests are taken for granted Do

    integration tests If possible, run cross- version, integration tests
  21. Questions?