Version Numbering

There is a strong desire to have the first official release be stable and feature rich. To that end there are a number of open source projects that are at version 0.something and have been for quite some time.

But there is a problem with that: Too many things break unless you have a clear and well structured version number plan. I try to follow Semantic Versioning. This allows you to clearly indicate that your API has changed and gives people upgrading a clear warning that something might break and they should allow time on the upgrade to rewrite affected areas of their own code.

Unfortunately, the Home Assistant project hasn’t figured this out and I was not clued in enough to closely read all the update notes between v0.81.x and v0.86.1 to realize that all my scripts, automations and presence detection would break. It took me two days to get everything working again as I was not prepared for the changes. Granted, some of the time was taken up by a failed microSD card. But most of it was taken up in researching new ways of achieving the same effect(s) as I had with the old APIs. Had I been warned via a changed top level version number of the incompatibilities I would have revised my scripts, etc. prior to attempting the upgrade.

Open source projects: Please don’t try to make the v1.0.0 release the perfect one honed by many incompatible updates on a v0.x series. If you’ve released (published) the project and people are using it, then bump the version number everytime you make an incompatible change.