core
core copied to clipboard
dotnet-websharper
Versioning strategy for external dependencies
I'm trying to update some tools created with a fairly old version of WebSharper. The app is dependent on some external libraries published as NuGets with WebSharper built libraries.
What I'm running into is that even minor versions have too larger a binary format change e.g.
Binary format version mismatch, found '4.5', expecting '4.7'
I don't directly control some of the external libraries built with WebSharper so I'd ether have convince the folks who do. One of the libraries isn't currently maintained so I'd need to fork it and publish an alternative NuGet.
I guess we'd also need multiple versions for each WebSharper binary format. Is there somewhere published where I can see the version numbers that need targeting?
Are we missing the right way to do this? Will it all just be better and stable going forward if we get them all updated to something modern?
You mentioned forking, so I assume you have source access to some or all of these external dependencies. If so, I'd just switch them all over to the latest WebSharper (should only require minimal or no code changes, and do use 6.0.x from the GitHub feed, the final 6.0 is out next week) and reap the benefits (targeting net60+, various code fixes, better translation for interfaces/collections, faster compilation with the WebSharper Booster, CLI support, etc.)
@Jand42 can tell you more about binary format changes (which AFAIK happen automatically on minor releases), those that happened lately definitely had performance and other improvements, so trying to pin to a massively old 4.x copy would be counter-productive.
Yes, the dependent projects are both open source https://github.com/SynBioDex/fSBOL and https://github.com/predictionmachines/FSharpIDD and are licensed such that I can fork them if we have to. I'd love to move everything up to WebSharper 6.0.x but we've got some constraints that the projects also target .NET Framework as well (hopefully to be deprecated soon), and we target netstandard2.0 among other things to support that. I think you folks dropped support for netstandard2.0 over here: https://github.com/dotnet-websharper/core/releases/tag/5.0.0.100-preview1
Should we be going about this differently? Would it be better to take a source dependency, potentially using Paket e.g. https://fsprojects.github.io/Paket/dependencies-file.html I'd like to avoid having to change all projects dependent on these libraries, some of which are closed sourced and I have less ready access to them.
@cgravill @granicz Hello, targeting netstandard2.0 and netstandard2.1 are still fully supported, WebSharper's own core libraries are using it too https://github.com/dotnet-websharper/core/blob/master/src/stdlib/WebSharper.Main/WebSharper.Main.fsproj#L3
As for the original metadata format issue, indeed it is enforced that all dependencies are recompiled with same major+minor version of WebSharper also because there are possible .js output breaking changes introduces between versions.
WebSharper 6.0 is in RC status, only doing utility and enhancements, no breaking changes planned.
Ah. @Jand42 that's great. I misread the breaking change note. That's great. We can try to move everything up to the current version.
Given the enforced recompile on minor version changes any recommendation of how you'd do it? Just take a direct source dependencies? I'm assuming there's no way to just pack the source into a NuGet etc and have WebSharper use that etc? We wouldn't want to have to have a NuGet suffix per minor version that might still be in use.
If those projects are already set up to create NuGet packages, I'd just make source dependencies, have them build their packages to a local folder, and use that as a NuGet source for the main project. @Jand42 any idea how versioning/referencing those packages would look like from the main project's perspective?
Just to be clear: the versions on the actual NuGet packages don't matter, what matters is that they are compiled with the same WebSharper (same major.minor version, that is.) So the only question is how to structure the build for the project tree and reference the packages that are built on demand.
Or a simpler idea: you might just get away with including the library projects via source (via git submodules) and use them as project dependencies in the main solution, bypassing NuGet entirely.