Do not use an upper bound on dependencies, unless you have to about fsunit HOT 5 CLOSED

@CaptnCodr many thanks for the quick resolution! I just upgraded and indeed, the issue doesn't repro anymore.

from fsunit.

Hey @abelbraaksma,
thank you for opening this issue. I'm currently looking into it.
I will probably release a new version this week.

from fsunit.

The reason why xunit (>= 2.5.3 && < 2.6.0) is the mechanism in paket, which packs the nuget package.
When there is a bugfix-version (2.5.3) then it ties it to the next minor version (2.6.0).
NHamcrest is tied to >= 3.3.0 && < 4.0.0 because there is no bugfix release else there would be the tie e.g.: >= 3.3.1 && < 3.4.0.

I will update the dependencies in the next PR and tie them to >= LOCKEDVERSION where LOCKEDVERSION is the newest version from nuget.

Edit: or tie the LOCKEDVERSION to the next major version, e.g.: xunit (>= 2.6.1 && < 3.0.0).

from fsunit.

Actually, you should make LOCKEDVERSION the lowest common denominator.

If you make it high, you force everybody using your library to also update xUnit, which, as we all know, introduces incompatibilities. You may need to, in which case there's no way out, but in any case, stay as low as you're code allows it.

If you can, don't give an upper bound. You don't want to run in the same situation again some day.

PS good to know that it's Paket making these decisions. They may make sense in company code, but not in shared libraries. In fact, with quite some public libs, I've seen Paket making weird decisions more often. You want the compatible version as long as possible as low as possible.

else there would be the tie e.g.: >= 3.3.1 && < 3.4.0.

So the same would happen again with FSharp.Core or NHamcrest. Maybe Paket is a little too much automation here?

from fsunit.

This has been fixed in v5.6.0 which is now available.

from fsunit.