Happy Friday. Let’s see what this week brought us…well, ironically, neither SmartThings or Google really brought us anything fun. Amazon finally fulfilled a request I put in when I first got the Echo…the ability to wake up to music (Amazon Alexa can now wake you up to music | TechCrunch). This is just on Alarms for now, but I would guess routines will have this in the future.
I still am setting up routines in the native Alexa app and connecting them Ask Alexa. THIS is almost the way I originally envisioned how a smart home should be; easy and do exactly what I want it to do. While there are still functions that I need to ‘ask Smart Things’, but now the majority of the items still use the power of SmartThings without having to say an invocation word. Very nice!
Once again, I have small Christmas present for everyone…a very small update to 2.3.5 of the main code and 1.0.6 of the Weather Extension code. This is general cleanup of the code, and adding the switch restrictions to the weather extension. This does not improve the install process I mentioned in an earlier post, but that is still a work in progress. On the good side, many of you reached out with brand new installs this week, so I am glad the tried and true process of the documentation still works.
This brings up a question many of you have asked me: how I keep track of the revisions. So I will focus this week’s essay on that.
Many of you know this already, but I work in the high tech industry. I am a manager of technology folks, which includes engineers, analysts, and programmers. As such, I have learned that version control (along with documentation) is one of the first things people skip, but is one of the most essential things in high tech. Internally, I keep track of daily revisions to the code use some sort of identifier…usually a data (2017123.1 for example…looks like a stardate from Star Trek!). MOST revisions don’t get released…they are for my own sanity…if I make a mistake in code and can’t remember what I did, I can always revert back.
When I am ready to release the code, I remove all remarked statements (to cut down on size) and give it a RELEASE increment number. For example, the MAJOR release is 2.3.5 of the main code. When I have a small revision that most people won’t see (a misspelling, or removing a remark or even a small obscure bug), I don’t change the date but add a small letter (a, b, c, etc) after the version number. Many areas of the code and extensions look at the major revision number to alert you if there is an upgrade needed. By keeping the Major revision the same, everything doesn’t need to get upgraded.
For major releases, I simply increment the number. The next revision of Ask Alexa, for example, will probably be 2.3.6. And if I make a MAJOR change to the code and functionality, I may go simple 3.0.0. While there are standards and best practices for revision, the most important part is not HOW you do it, but to do it at all. It allows you (the users) to know when you have the latest version, and it keeps me sane by allowing me to roll back a version if I run into issues.
Happy Holidays!