Bump to 2.6.0

[gabrieljoelc]

See the diff between v2.5.0 and master. Looks like a minor version bump to me. Proposed changelog/release notes:

• Added licence type to gemspec Add license to gemspec. #274
• Serialization content type configuration Content type (de)serialization #152
• Add NewRelic category to example Indicate that worker is a background task for NewRelic #273
• Pass additional global Bunny session configuration Ability to pass 'properties' to Bunny session #276
• Sneaker.spawn exits with exit_code 1 when no configuration is provided Exit the spawner with a status code. #280
• Added opt-in option for sharing bunny connections for worker group added shared connection option for worker group #266
• Bumped bunny version from 2.6.* to 2.7.*. Bumped bunny version #289
• Relaced thread gem with concurrent-ruby gem Replace gem thread with concurrent-ruby #279
• Fixed "stack level to deep" error when trying to serialize the exception object in maxretry handler Avoid stack level to deep when trying to serialize the exception obje… #308

Is #279 the one that has the greatest chance of side-effects in production?

[michaelklishin]

@gabrieljoelc the change log looks OK. A bit more detail (à la Bunny) would be better but we can worry about that after the release.

[gabrieljoelc]

Pushed to rubygems.org: https://rubygems.org/gems/sneakers/versions/2.6.0.

[michaelklishin]

@gabrieljoelc just as we expected, #279 introduced a subtle change that can break things. I fixed one of them in #312 (too early to tell how many will run into it) and created a 2.6.x-stable branch for 2.6.1. We should probably produce a new release tomorrow.

This raises a question: in Bunny, older series branches are merged into master. Is it something you'd subscribe to? Some are big believers in cherry-picking from master but in many years maintaining Bunny I tend to first patch the oldest branch. This way you cannot forget to backport.

[gabrieljoelc]

@michaelklishin yes, that looks like the right hotfix.

I'm not sure I'm following you. When I created the 2.6.0 release branch, I had the feeling that I wished we were just doing git flow:

• develop branch we could continually merge to
• intentional release branches of develop that we bump the version and merge into both master and develop
  I'm not sure if that helps with what you were describing.

[gabrieljoelc]

@michaelklishin do you want me to create a hotfix release with 7e96d48 today?

[michaelklishin]

@gabrieljoelc in Bunny there are stable release branches (e.g. 2.6.x-stable and master). We can add develop into that but for smaller projects I'm not sure what the benefit is. But I'm not necessarily against it. Either way, it's a fundamental decision: do changes go into the oldest branch first and then merged all the way up to master, or into master first and then cherry-picked all the way to the oldest branch.

Bunny does the former. RabbitMQ currently does the former but there's an ongoing debate on our team about switching to the latter at some point. Both can work but the former makes it impossible to forget to propagate a change to all branches.

[michaelklishin]

@gabrieljoelc sure, feel free to release 2.6.1 when you have a moment.