Toward version 0.1

[danielwelch]

@ciotlosm

Seems like we're nearing a point where we can go to a first versioned release. Creating a tracking issue to that end:

• [x] resolve #15

• [x] resolve #2 (add pm2)

• [ ] determine how to handle versioning / releases

[ciotlosm]

I think this is very accurate. I was hoping to do pm2 yesterday, but the OPI setup delayed me. I will try today in a virtualised environment to do the pm2 setup and create a merge request for both #15 and #2

[danielwelch]

@ciotlosm So, with the changes in your latest pull request, I think we're ready for a 0.1 release.

However, the biggest problem is how we will track updates of the zigbee2mqtt repository and rebuild/push new docker images which each update of the master branch there. The current proposed solution in #19 is to trigger a travis build of this repo/image after each successful build of the zigbee2mqtt travis CI. This is a good option, but does not integrate perfectly with the workflow of the add-on release cycle using the build-env tool that this repository uses:

• on each build and docker push, if the corresponding git commit is tagged, the docker image will be tagged latest and with the git tag version number.
• however, if the commit is untagged (as would be the case for all builds triggered by updates to zigbee2mqtt), there is no version tag assigned, and the test tag is applied.

I'm not sure how the hass.io UI and add-on management system will respond in this instance, as I've only published using versioned releases. I certainly don't think it will allow for the very nice "update available" UI, and I suspect that tagged releases and the test releases could not exist alongside each other (users would probably be "stuck" at the last tagged release and not presented with an option to "update" to the newest test image).

My first thought: could the node script referenced by @Koenkk in #19 be modified to tag and bump the sub-version with each build?

[ciotlosm]

@danielwelch I think there could be another approach:

• Keep 0.1 as stable version
• Create a secondary repo that uses "test" image for people that want to use "unstable" - or some other alternative for this

Another option would be to allow @Koenkk to trigger a version increase / tag (so addon gets updated to 0.2, 0.3 etc.) when he thinks that the changes he has done are stable enough to get published.

Update: After reading again I think increasing minor version on each webhook trigger should be ok. We an always stop such process when we have a stable version on https://github.com/Koenkk/zigbee2mqtt starts using tagged releases.

[danielwelch]

@ciotlosm I agree that whatever we decide to do here, this should be a temporary measure until https://github.com/Koenkk/zigbee2mqtt development slows down and we start doing tagged releases.

The more I think about, the more I think we should just avoid a versioning release until https://github.com/Koenkk/zigbee2mqtt adopts one. I don't think we'd be able to use git tags, which is how the automated build-env system manages the docker tags, so we'd have to handle those separately, which would be a pain.

[Koenkk]

Would it be an idea to give me write access to your repo? In this way I can automatically add tags to to the latest commit which would then trigger a rebuild.

[danielwelch]

I’m ok with that. Note that for each new tag, you’d have up to update the corresponding version key in the add-on config.json

[Koenkk]

So updating https://github.com/danielwelch/hassio-zigbee2mqtt/blob/master/zigbee2mqtt/config.json#L3 everytime with the latest zigbee2mqtt commit hash would be ok?

[danielwelch]

That line needs to correspond to a docker tag. The build-env tool we use to build and push docker images will automatically tag docker images with version tags that match a corresponding git tag that is built in Travis. So, if a commit tagged v0.1.1 is found, the resulting docker image will be tagged “0.1.1” and the config line needs to be updated to 0.1.1 for users to be presented with an option to update.

[danielwelch]

@Koenkk I wrote a web service that, in response to push events from a github webhook, will trigger travis builds for this repository. It's deployed on heroku. If you'd like to tie into it, let me know and somehow I'll securely send you the URL and required secret.

[Koenkk]

Great! I'm on telegram: @koenkk

[danielwelch]

For whatever reason, I can't find that username on the global search. I'm on telegram @dwelch, maybe you'll have more luck

[ciotlosm]

Is there any way for users to do version pinning to a specific zigbee2mqtt version if some users desire it?

[danielwelch]

In zigbee2mqtt's current state, I suppose we could expose that as an optional config variable in the UI, and then just use git to get a specified version. What's the use case, out of curiosity?

[ciotlosm]

I'm just thinking of "worst case scenario". Let's say zigbee2mqtt gets a PR merged that breaks some functionality that was not tested - like a setup with many sensors, and neither of us is around to roll it back or fix it for a few days.

As users area already starting to use the setup on the "production" systems, I guess it would be nice to have a backup emergency plan so nobody gets punished by their significant other :-)

[danielwelch]

Not a bad idea, especially since without versioned releases we're really relying on the stability of the "bleeding edge" of zigbee2mqtt

[danielwelch]

@ciotlosm see #23

[ciotlosm]

I think we should modify this to use https://github.com/Koenkk/zigbee2mqtt/issues/96 as dependency. Everything else about the addon is in right working condition.

[danielwelch]

Yes, as soon as there’s a stable 0.1 release I’d say we can modify to use that and release a 0.1 ourselves. Would it be worth it to include an option to use the latest master (I’m thinking if someone wants to test/develop while using the addon)?

[ciotlosm]

@danielwelch totally agree

[danielwelch]

@ciotlosm I think the nicest way to handle this dual offering, when the time comes, (stable 0.1 alongside latest master of zigbee2mqtt) may be to do something similar to what esphomeyaml is doing. Ottowinter is providing 2 add-ons, a stable version and edge verions, both installable from the same Hass.io repository.

This way, we can customize the build process a little better (for example, the git clone depth difference would become a non-issue).

[ciotlosm]

@danielwelch I was wondering if that possible. I think it's a really good way to do it. 👍

[kjetilmjos]

Zigbee2mqtt just released their first versions release a day ago.

[talondnb]

Will this also be released? Any ETA on when?

[danielwelch]

Yes, this will be released soon (few days). I’d like to do a versioned release which clones zigbee2mqtt’s release, and a separate add-on (same repository) for an “edge” version that will operate similarly to how this add on has worked so far, tracking master

[danielwelch]

See #36