showDiff=true for members, fix #572

[scottbessler]

As per the discussion in #572, ensuring showDiff=true for members assertions

[meeber]

@scottbessler Do you know if you're still experiencing this issue with Chai's 4.0.0-canary.1 release? Because I suspect #574 already fixed it (by enabling showDiff by default unless explicitly disabled by passing in false).

[scottbessler]

It looks fixed in 4 but don't usually use pre release deps :)
On Mon, Nov 7, 2016 at 4:33 PM Grant Snodgrass notifications@github.com
wrote:

@scottbessler https://github.com/scottbessler Do you know if you're
still experiencing this issue with Chai's 4.0.0-canary.1 release? Because I
suspect #574 #574 already fixed it
(by enabling showDiff by default unless explicitly disabled by passing in
false).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#863 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAR7qvqA4U6kUlojaasvnIcx7iwpeWzXks5q78NAgaJpZM4Kr4qV
.

[meeber]

Gonna go ahead and close this since it's fixed in the upcoming release. Shouldn't be too long; we don't have any other major changes planned prior to release. Thanks for the PR!

[scottbessler]

Doesn't 4.0 have breaking changes? Seems unfortunate to just close when all
this should take is a merge and publish of 3.5.1 Oh well I guess I'll just
point at my repo for now.
On Mon, Nov 7, 2016 at 5:13 PM Grant Snodgrass notifications@github.com
wrote:

Closed #863 #863.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#863 (comment), or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAR7qtvwg_ST21G2dNkT8WessQmjUgjWks5q78zSgaJpZM4Kr4qV
.

[lucasfcosta]

Hi, @scottbessler thanks for your PR!
Well, since this has been solved on 4.0.0 only, I think it may be a good idea to start porting fixes to our previous versions too, however, this only happened as it is now because we took too long to release 4.0.0. Ideally we would have released some intermediary versions with fixes and only then we would release 4.0.0.

I totally understand your point and it does make sense, but let's hear what other team members have to say about it.

I hope you understand, sorry for that 😅

[keithamus]

We were only discussing this yesterday! My points here #862 (comment).

Not ideal that we're making such a jump from 3.5 to 4, but in the future it wont be necessary as every PR will be a release. I have no opinion about making effort to backport to 3.x versions.

[meeber]

As with most things, the primary cost of backporting fixes to 3.x is time.

The commit that fixed this issue in 4.x (by making showDiff default to true instead of false) is what I'd consider a low-impact breaking change, but a breaking change nevertheless. Therefore, to backport this fix to 3.5, a different fix (such as the one introduced by this PR) would need to be applied instead, thus resulting in divergent branches. Diverging branches doesn't have a noticeable impact if we're just backporting a handful of small fixes, but if the desire is to continue backporting fixes in the future, then the impact of divergent branches is cumulative; it takes increasing amounts of time to apply fixes to increasingly divergent branches.

Consider also that if we wish to start backporting fixes, then we'll need to reconfigure our CI to apply the appropriate node/browser version testing based on Chai version.

There are certainly some low-hanging fixes (such as this one) between 3.5 and 4.0 that could be backported without a huge time investment, but anything beyond that quickly ramps up.

Anyway, I don't see anything wrong with someone volunteering their time to take up that burden as long as it doesn't create the expectation that it must be carried by everyone going forward.