Fixes for v0.9.7

[blag]

Pulling the fixes from #192 into the 0.9.7 branch.

This was manually tested separately from #192 with a minimal Mattermost installed on VM.

[arm4b]

Uh oh

I get the idea of releasing an isolated fix to the user, but let's please avoid detached/split releases like that in future.

Instead we should try to release more frequently from master.

[arm4b]

Don't forget to apply respective Github labels for better Issues organization.

[arm4b]

Also after merging this, how do you plan to sync-up changes back to the current master?

[blag]

I get the idea of releasing an isolated fix to the user, but let's please avoid detached/split releases like that in future.

Instead we should try to release more frequently from master.

I was following SemVer:

PATCH version when you make backwards-compatible bug fixes.

AIUI, this is the same approach we take in st2, where we have feature and bugfix releases.

Instead we should try to release more frequently from master.

I don't quite understand how that would help this situation, can you explain a bit more?

Also after merging this, how do you plan to sync-up changes back to the current master?

I don't. The v0.9.7 branch will only receive bugfixes until we release a version of st2chatops that contains hubot-stackstorm version 0.10.0 or higher.

PR #192 is the same fix for master. Please give #192 and #193 a review when you have a chance. Once that's merged I'll have a version bump PR for version 0.10.0 and release that as well.

[arm4b]

It may look similar, however both git history and results are different.

For the st2 repo we maintain the versioned "stable" branches, which is not the case for repositories like hubot-stackstorm. In st2 every change is first merged into master and then cherry-picked into respective branch, but not like we do here with git brain split situation when v0.9.7 is not a subset of master.

After all you'll still need to include in master Changelog for the 0.9.7 release, and master history shows different git log and order for the fixes.
To avoid this, ideally to release more frequently from master once the logically sufficient change was made. And so we'd release v0.10.0 with refactoring, v0.10.1 with some other fixes and v0.10.2 with Mattermost bugfix, all based on master, preserving consistency.

[blag]

Instead of having a bugfix release branch around indefinitely, I think users will need to manually apply these two commit diffs:

1cb50ac
d89bd18

Closing.

[arm4b]

For the temporary fix before we officially release v3.2 for st2 and st2chatops, installing hubot-stackstorm v0.10.0 would be fine too.

[blag]

Just a note: hubot-stackstorm v0.10.0 does contain a giant amount of refactoring. The intent with this branch was to get users of older versions of hubot-stackstorm (eg: v0.9.6 and below) a fix/patch that did not include the refactoring work going on.
¯\_(ツ)_/¯

[arm4b]

That's hopefully OK, considering that refactoring is non-breaking and didn't really introduce any changes.
After all we're going to rely on that in next st2 release.