Create a branch off of 1.4.1, so PRs can be made against that version

[technicalpickles]

I was debugging slackapi/hubot-slack#203 and the fix ended up being in node-slack-client. I have a branch off of that, but I can't make a PR for it because the only branch is master.

To create, it'd be like:

• git checkout 1.4.1
• git checkout -b 1.4.x
• git push origin 1.4.x

[technicalpickles]

Actually, it'd be better to make it 1.x rather 1.4.x, assuming we are using semantic versioning.

[ghost]

https://github.com/slackhq/node-slack-client/tree/1.5.0 is now a thing

I'd be interested in chatting about what kind of upgrade path to future versions of the node-client you're thinking of. There's been a lot of work on handling reconnection logic since 1.4.1 and there'll be some additional features around that coming shortly as well.

[technicalpickles]

https://github.com/slackhq/node-slack-client/tree/1.5.0 is now a thing

Thanks. I was actually thinking to literally call it 1.x so if there's any other changes, that can effectively be the master of the 1.x line, so PRs can be made from that. That way, it's a little more future proof than just this one change, specifically so we don't have to make more branches named like that or have it be confusing if we keep making changes against it. Also: I think it would conflict with a 1.5.0 tag whenever that happens.

I'd be interested in chatting about what kind of upgrade path to future versions of the node-client you're thinking of. There's been a lot of work on handling reconnection logic since 1.4.1 and there'll be some additional features around that coming shortly as wel

I'd ask you the same thing since you've been working on this 😁 If you are using semantic version, 2.0 is a major release, and does allow for breaking API changes. However, that doesn't necessarily make it easy for people to upgrade to it.

I'd start with upgrading an existing application using 1.x to 2.x, and just see what breaks. hubot-slack would be a good one, but maybe it's too complicated to try for the first pass. I think that would highlight a bunch of changes. If there are a lot of things breaking, it'd be worth asking backwards compatability should be added to the 2.x branch.

If there are specific things that are definitely changing in 2.x, it's worth adding deprecation messages in 1.x. If it's functions or events being rename, you can keep the old one there, log the deprecation, and then pass it onto the new thing. If it's function parameters changing (ie adding more parameters), you can check the function arity to conditionally do an old behavior and log the warning, vs doing the new behavior. By doing this, something using the older version of the library would get hints on how to upgrade.

[ghost]

1.x is up at https://github.com/slackhq/node-slack-client/tree/1.x. I'll write up a response to the other questions this weekend.

[aaronblythe]

I would be interested in seeing the other responses. :) Trying to gauge if I use a work around or wait for #183

[DEGoodmanWilson]

Is this issue resolved?

[technicalpickles]

This particular issue, ie having a 1.x branch is resolved, see https://github.com/slackhq/node-slack-sdk/tree/1.x