Closed einarmo closed 1 year ago
Merging #122 (b465a76) into master (c4f2fe0) will decrease coverage by
0.15%
. The diff coverage isn/a
.
@@ Coverage Diff @@
## master #122 +/- ##
==========================================
- Coverage 76.80% 76.66% -0.15%
==========================================
Files 9 9
Lines 677 677
Branches 39 39
==========================================
- Hits 520 519 -1
Misses 131 131
- Partials 26 27 +1
I'm a bit worried that this will force all dependents to .NET 7. What we need is something like e.g nuget FSharp.Core >= 6.0.0 lowest_matching: true
so we generate a >=
dependency in the lock file.
I'm a bit worried that this will force all dependents to .NET 7. What we need is something like e.g
nuget FSharp.Core >= 6.0.0 lowest_matching: true
so we generate a>=
dependency in the lock file.
It couldn't possibly, right? This library is built for .NET standard, we wouldn't be able to build it at all if the dependencies required .NET 7.
dependents (down stream), not dependencies (up stream)
dependents (down stream), not dependencies (up stream)
My comment was a bit unclear, I think. If dependencies required .NET 7, Oryx would not compile for .NET standard, which is compatible with .NET Core 3 and .NET framework 4. If Oryx compiles at all, any dependents would be able to run any version of .NET that is compatible with .NET Standard 2.0.
Maybe you will get rid of Paket and do muti-targeting?
I have a lot of annoying warnings because of weird Paket version locks
I'm fairly confident this will be fine, the PI and PI AF extractors are running 7.0 versions of several core packages, and they are built for .NET framework. I don't see how this bump to 7 is any different from the previous versions, which were 6.
Projects are running into conflicts due to .NET 7 dependencies.