Support RMQ client 3.4

[particular]

Support RMQ client 3.4

[johnsimons]

Why? What is the benefit?

[johnsimons]

Since the RMQ team is not strict about semver

We cannot use dependency ranges, so we always have to be strict on the version including the patch number

[andreasohlund]

They are strict for patches as it seems?

[johnsimons]

@andreasohlund I would not put my money on that.
IMO to be safe, we should be strict on the version including the patch number

[andreasohlund]

So we would have to release a new version for each patch of RMQ?

Sounds like a maintenance issue?

Sent from my iPhone

On 07 Nov 2014, at 03:38, John Simons [email protected] wrote:

@andreasohlund I would not put my money on that.
IMO to be safe, we should be strict on the version including the patch number

—
Reply to this email directly or view it on GitHub.

[johnsimons]

@andreasohlund
Hence my initial question, what is the issue we are fixing by updating to the latest of the latest ?
Are there any outstanding issues that out customers are facing that are addressed by updating the rabbit client ?

[andreasohlund]

But by locking on patch users can't update the client until we update?

[johnsimons]

Are users using the rabbit client assembly themselves?
What for?

[SimonCropp]

@andreasohlund well if rabbit is making breaking changes on each release they can update till we do anyway. at lease the nuget lock is a explicit failure at build time rather than a method/field not found at run time

[SimonCropp]

@johnsimons assuming they want bugs fixes/perf improvements that re included in the new rabbit versions???

[johnsimons]

@SimonCropp totally agree, but the users would not need to reference the rabbit client assembly directly.
That would be a normal update.

[andreasohlund]

@johnsimons I can't come up with a use case. I stand corrected. Lets go with a lock on exact version

Sent from my iPhone

On 07 Nov 2014, at 07:34, Simon Cropp [email protected] wrote:

@andreasohlund well if rabbit is making breaking changes on each release they can update till we do anyway. at lease the nuget lock is a explicit failure at build time rather than a method/field not found at run time

—
Reply to this email directly or view it on GitHub.

[johnsimons]

Lets go with a lock on exact version

In the latest release I have already locked it in

[johnsimons]

So @andreasohlund, why do you want to update to the latest of the latest ?

[andreasohlund]

Not urgent, we'll do this as soon as users starts asking for it

On Fri, Nov 7, 2014 at 8:02 AM, John Simons [email protected]
wrote:

So @andreasohlund https://github.com/andreasohlund, why do you want to
update to the latest of the latest ?

—
Reply to this email directly or view it on GitHub
#53 (comment)
.

[andreasohlund]

I plan to do a 2.1 release soon. Any reason we shouldn't update the client? (3.4 has been out since october 27)

[johnsimons]

Has anyone asked for it?

[SimonCropp]

well since we r strict on versioning with this lib dont we need to update for anyone to get the fixes in the newest version of rabbit client?

[SimonCropp]

http://www.rabbitmq.com/release-notes/README-3.4.0.txt

.net client
-----------
enhancements
26130 automatic connection recovery similar to that of the Java client
26208 add APIs to make methods easier to use in nowait mode
26324 introduce an interface for ConnectionFactory
26334 set up stream timeouts as early as possible (thanks to John Oliver)
26199 allow IO and heartbeat to be background threads
25525 allow Subscription class to set explicit consumer tag
26097 add support for nack / reject in Subscription
26122 remove unnecessary lock in Subscription

[johnsimons]

Well is there any known issue with the current version we are on that affects any of our users?
Or is there anything new in the new version that we want to take advantage of?

[SimonCropp]

Well is there any known issue with the current version

See above

that affects any of our users

difficult to tell

Or is there anything new in the new version that we want to take advantage of

perhaps ConnectionFactory changes? @andreasohlund

[johnsimons]

The way I see it is that there is less risk for us to stay with the version we are familiar with and have been supporting, unless there are compelling reasons to update to latest

[SimonCropp]

would prefer to iteratively upgrade to new versions after a safe wait period. in this case 3 months.

Better then someone saying "i need version 3.8" in 6 months and we then do a huge jump.

So I say embrace frequent change with appropriate measures to mitigate the risk.

Also from a consumer perspective they would be safe to assume new version of NSB.RMQ release today should have the the version of the client from several months ago.

Also there is risk in not updating since someone may need to use the 3.4 native API inside an endpoint. Any bugs they have with incompatibly between our expectations of compiling against an older version and the new version would be our problem to fix.

[andreasohlund]

I'm with @SimonCropp here. We have an extensive test suite that will catch
any major issues. Falling to far behind is a bigger risk imo. Since the
client has been out for 3 month it should be stable and I would expect our
existing users to wanting to update and new users would definitely want to
be on the latest version

I'll include this in the 2.1 release

On Fri, Feb 6, 2015 at 6:21 AM, Simon Cropp [email protected]
wrote:

would prefer to iteratively upgrade to new versions after a safe wait
period. in this case 3 months.

Better then someone saying "i need version 3.8" in 6 months and we then do
a huge jump.

So I say embrace frequent change with appropriate measures to mitigate the
risk.

Also from a consumer perspective they would be safe to assume new version
of NSB.RMQ release today should have the the version of the client from
several months ago.

Also there is risk in not updating since someone may need to use the 3.4
native API inside an endpoint. Any bugs they have with incompatibly between
our expectations of compiling against an older version and the new version
would be our problem to fix.

—
Reply to this email directly or view it on GitHub
#53 (comment)
.