Restrict LiteDB dependency version to 4.x #49
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As noted in #45, LiteDB.FSharp is currently incompatible with LiteDB 5.x due to API changes, but it is possible to install them together, as LiteDB.FSharp does not restrict the version range for the
LiteDB
dependency. The user will only learn about the incompatibility at runtime.This PR does the following:
LiteDB.FSharp
via simpledotnet pack
with Paket using a template file to allow for specifying dependency version ranges (This is not possible at this time withdotnet pack
in a project using Paket for its own dependency management, due to Losing version-range when 'dotnet pack' fsprojects/Paket#2883.)LiteDB
dependency to 4.1.4 <= x < 5.0Release
configuration and the created package tobin
in the repository root. This seemed more appropriate when not using the built-in package creation withdotnet pack
.Using the Paket template file means that all the package metadata entries have been moved over there. I have not looked into potential ways of having FAKE/Paket transfer the information over from the project file during the build process, as it didn't seem worth the effort. It's still all in one place, just in a different file.
I have tried to keep the resulting
.nuspec
file in the package as close as possible to the previous one.This is the
.nuspec
file currently live on NuGet:This is what is generated by this PR:
The dependencies are filled automatically by Paket, relying on the information in
paket.dependencies
andpaket.references
. This avoids having to maintain them in multiple places, but causes them to be listed only once instead of for each individual platform target. I'm not sure if that might allow installing the package into projects using incompatible platforms, but I think it shouldn't.The files to include in the package are also determined automatically by Paket and are identical to those currently included.
As before, I have not tested publishing the package.