MatchException does not exist anymore in 2.5.0

[abelbraaksma]

Description

Basically, binary incompatibility. MatchException, a public type, was removed from the surface area. See #240.

Repro steps

Any code that used MatchException for their own extensions:

Expected behavior

• Either the MatchException got a deprecation message prior to removing it
• Or the MatchException would be mentioned in a wiki or readme or release notes, plus how to replace it with a new type
• Or the MatchException remained in place, even if it is just a placeholder type

Actual behavior

The type is gone.

Known workarounds

None yet. But I'll research. Probably there's a "new way to do things", which is primarily why I report this, so that others can find it too.

Related information

Version 2.5.0. Older releases did not have this problem. It was introduced after updating the similarly (and notoriously so, they do this all the time) backward-incompatible changes of xUnit, which they did on a minor release (2.4 -. 2.5). Not a critique on this library, though!

[CaptnCodr]

Hi @abelbraaksma,
I asked after this change has been done in the xunit repository: xunit/xunit#2744

Some users (including me) are concerned about that change in a minor version.

There are several exception types for different use-cases.
The MatchException is completely gone.
I think there are no wiki/readme mentions about how to upgrade to xunit 2.5+.

But I think as you already changed the code in FSharp.Control.TaskSeq is the right way as it thought.

[CaptnCodr]

Hey @abelbraaksma,
is this cleared up? Do you want to add some more here? 🙂

[abelbraaksma]

Apologies for missing your updates, @CaptnCodr. I got distracted and forgot ;).

Just today I find myself upgrading several large projects of a customer, and searching again for the missing MatchException after upgrade. This time, it is a widely used xUnit extension in a package used throughout the company.

This makes updating it that much harder, if not impossible, as at least for some time we will need to support both the old and the new version of xUnit. My creative solution now is to use contentFiles with two versions of the source files of the extensions, and updated the dependencies depending on their xUnit version (using PrivateAssets and IncludeAssets to get the proper file, if that's gonna work).

Backward incompatibility is tough to deal with (not saying you shouldn't move forward, but yes, as you mentioned, never do that on a minor version).

Anyway, thanks for getting back to me at the time. No need to reopen.

[abelbraaksma]

My creative solution now is to use contentFiles with two versions of the source files of the extensions, and updated the dependencies depending on their xUnit version (using PrivateAssets and IncludeAssets to get the proper file, if that's gonna work).

follow up: a terrible idea. Not in principle, but because it requires manual changes in the fsproj or csproj after you lib is added. The contentFiles approach itself is fine for source inclusion, but not with multiple versions of the same file.