Current Packages are not compatible with FsPickler 4.0

[0x53A]

FsPickler 4.0 was just released, unfortunately most packages have a hard dependency < 4.0:

If FsPickler 4.0 is binary compatible (on the assembly level, whether the serialized blob is compatible would not matter to me in this case) to the previous versions, then it should be enough to repackage the current assemblies with an updated version range.

In my specific case, the conflicting dependencies are

MBrace.Thespian
MBrace.Runtime
Thespian
Vagabond

but I would guess that the Azure / AWS packages are also affected.

[eiriktsarpalis]

The problem is, the package is not binary compatible. There's a long chain of dependencies that need to be updated to support this.

[0x53A]

Do you think it would be

a) possible and b) desirable

to restore binary compat between 3.x and 4.x, or was the break on purpose to be able to clean up the api?

I'm currently not totally blocked - we run my fork (built from my now closed PR) in production, but that is not a viable strategy long term.

Otherwise, are there any big blockers in porting these packages to FsPickler 4.0, or is it "just work"?

If it is "just work", I can try to take a look. (I know I have said the same w.r.t. porting Argu, and I still have it on my long list ...).

---

If possible at all, then it would be great if FsPickler could be made bin-compatible again, because we use FsPickler both as a direct dependency (serialization for Akka Actors) and a transitive dependency (MBrace / Thespian), so that hurts a little bit ...

Thank you.

[eiriktsarpalis]

I don't think it's desirable to revert backward compatibility. The best approach is to release updates on the entire Vagabond -> Thespian -> MBrace.* dependency chain. I'm not actively working on this project anymore, so can't promise when I'll have the time to do this.

[dsyme]

I don't think it's desirable to revert backward compatibility. The best approach is to release updates on the entire Vagabond -> Thespian -> MBrace.* dependency chain.

I took a look at this a while back and was surprised how much was involved.

If we decide to do this, I do wonder if we could just collapse all of Thespian and MBrace.* into a single solution which doesn't have intermediate nuget packages. There are big downsides to doing this (the current componentization is nice, and you can work on MBrace.Azure without working on MBrace.AWS), but the cost of maintaining and releasing the separate components doesn't seem worth it.

[mikev]

just collapse all of Thespian and MBrace.* into a single solution which doesn't have intermediate nuget packages.

I agree. Further I think the world has changed a bit, since 2015. MBrace could simplify to just two cluster solutions. First would be to support a Kubernetes/Linux/DotnetCore cluster. That solution provides cross-cloud support for AWS, Google and Azure's Kubernetes. Second would be to support an Azure/Windows cluster. I think the case for supporting an AWS-only cluster is small. In any case, having a single solution would make it easier to build these.

[isaacabraham]

@mikev funnily enough I was chatting with someone today and we said exactly the same vis-a-vis K8s. There would still need to be the ability to source data from multiple systems but as long as there's a way to do the following, we would be good to go.

• Store (potentially large) state across the cluster, both on the node itself and across all nodes
• Perform reliable messaging and queuing between nodes and at the broadcast level

We looked at using Azure Service Fabric some years ago but K8s definitely seems the way to go now.