And so we reach the end of another coding-year, and while many of us are plotting our holiday hacks and offline AR (actual reality) adventures, there are a few folks who still have to launch features over the break.
Ok, so now you’re charging ahead anyway, without your whole team on board, it’s a period of heightened risk and it’s important that you approach production changes with an appropriate level of caution and care.
“Initial commit” is so uninspiring yet we’ve all committed it somewhere!
I’ve recently found myself creating a noticeable handful of repositories for various projects and it got me thinking: whats in a first commit? It’s the commit that hangs around like a bad smell for years after you make it. It appears in github in that placeholder .gitignore, or in that tiny file that never gets changed. So why think about it?
Backwards compatibility is one of the most crucial factors of when and how to release a new feature. Maintaining a stable API while constantly improving your service is critical - you don’t want to be breaking your API clients every second Tuesday. In this simple example I want to share how fields that are enums (commonly status fields) are crucial parts of your API stability and how changing them is a terrible idea.