quick review, and we can release 6.1.4 <https://gi...

# kotest-contributors

[sam]

quick review, and we can release 6.1.4 https://github.com/kotest/kotest/pull/5686

[Emil Kantis]

approved, but had a question

[sam]

thanks, replied and did what you suggested

[Emil Kantis]

re-approved

[sam]

ty

[Oliver.O]

So fast! Thanks a lot! ❤️

If you're about to release 6.1.4, there's one other thing I'd love you to reconsider:

Kotest 6.0.0 changed the package of errorCollectorContextElement from io.kotest.assertions to io.kotest.matchers, a breaking change not mentioned in the release notes. (That element governs coroutine thread-safety for assertSoftly and withClue, so it is not really part of the matchers.)

Would you mind changing it back? It's the only symbol I'm using in the TestBalloon Kotest integration and avoiding this breaking change would mean users could choose when to upgrade Kotest Assertions from 5.9.1 to 6.1.4 (versions in between would have to be skipped, though).

[sam]

Yes I'll revert that too

[sam]

I'll add a typealias so it works for all

[Oliver.O]

Thats fine, if io.kotest.assertions.errorCollectorContextElement is the JVM symbol and io.kotest.matchers.errorCollectorContextElement the typealias (which only works at the source level and cannot offer binary compatibility).

[sam]

I'll move it back and add the typealias for the new name for anyone in between

[Oliver.O]

That's cool. Usually with test libraries, we have the luxury that source compatibility is good enough in most (end-use) cases.

[sam]

I didn't consider anyone external was using error collector so my bad

[Oliver.O]

It's only needed when you're using the assertions library without the framework. And even then, as long as your coroutines are guaranteed to run on a single thread, you can get away without the context element. If not, interesting stuff starts to happen. 😉

[sam]

Gotcha