When building software, it is possible to optimize for any two of these three attributes:
- Ship early and update often (to get feedback from real customers)
- Have the flexibility to fix mistakes (so if you build something but later realize it would be better done a different way, you are able to change it)
- Avoid breaking changes (it quickly gets annoying for customers if every time they update to a new version their code no longer compiles, or if things they considered finished are now done a different way)
Most projects I worked on in the past focused on #2 and #3 at the expense of #1. In order to fix mistakes without breaking customers, development took place in private, and new versions were only released once the team believed at least most of the mistakes were gone.
We are trying something different with Win2D, optimizing for #1 and #2 at the expense of #3. We release new code every two weeks, warts and all, and fix things later if time or feedback shows us ways to make it better. One of the nice things about being open source with side-by-side versioning is that we can for instance rename a method, yet existing apps will only be affected if their developers choose to upgrade to a newer version of Win2D, so there is no risk of the rename breaking apps that have already been released.
I’m mostly very happy with this approach, but I sometimes worry our breaking changes might be too annoying. I would love to hear your feedback on this. If you are using Win2D, do you update every time we release new code? How straightforward are you finding these updates?