This means that the SDK, after months of hard work and feedback, is beta quality. The SDK has been well tested, and most major API changes have been settled. We will try not to make breaking changes, but if we have to, we will of course call them out very clearly in the release notes. In addition, we also added experimental Worker Versioning support and DI helpers for clients (with lazy client connection support). See the release notes for more information.
Tell your friends! For us to get to GA, we need any/all feedback, good or bad, about how well the SDK is working for you and what is missing. (You can post here or create an issue.) Thanks!
Is there a progress plan for .NET SDK that you could share with the community that would give some visibility on what’s left for a v1 release? In other words, even if you can’t give us a expected delivery date for a v1 release, can you at least share the scope of a v1 release?
E.g. what are all the various things/user stories/requirements etc. that need to be completed before we have a production-ready .NET SDK? I’m assuming this must be known on your end given you’ve moved from alpha to beta, which must correlate back to some project milestones you’ve set, otherwise why bother!
This would be useful for other reason e.g. planned feature parity with other SDK versions, like Java.
i.e. I’d love to know if side effects are even in scope for a v1 release.
We consider the current version production-ready, and many are using it in production. I believe the v1 decision is more about a commitment to not changing the API, and we’ll grow confidence that we don’t need to change the API the more that folks use it.
expected delivery date for a v1 release, can you at least share the scope of a v1 release?
I don’t know if we have a date, and I’m not aware of any features that are planned before v1. @Tasha_Alfano might have more info.
planned feature parity with other SDK versions, like Java. i.e. I’d love to know if side effects are even in scope for a v1 release.
I believe it already has feature parity on all planned features but Update (currently in development), and that side effects and sessions are not planned, as we recommend instead using local activities and worker-specific task queues, respectively.
