search

StackStorm / hubot-stackstorm

Hubot plugin for integration with StackStorm event-driven infrastructure automation platform.
Apache License 2.0
49 stars 39 forks source link

Fixes for v0.9.7 #193

Closed blag closed 5 years ago

blag commented 5 years ago

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 commented 5 years ago

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

arm4b commented 5 years ago

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

blag commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

https://github.com/StackStorm/hubot-stackstorm/pull/193/commits/1cb50ac344a78c65e42f7a0ff88843a8952f8645 https://github.com/StackStorm/hubot-stackstorm/pull/193/commits/d89bd18c1048a36f563b0c9fc8d73b54c52ec0f2

Closing.

arm4b commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.