Update release process README

[marcduiker]

The current process does not explicitly mention the difference of releasing the runtime and SDKs. For instance, the SDKs are not (always) released on the same day as the runtime. For SDK contributors, it would be good to know when the protos are frozen so they can continue with a stable interface. Although the current process does describe the requirement of tests and docs we should be more alert on specifically the documentation part to not leave this to the latest.

An updated release process should provide better expectation management for both end users and contributors.

[olitomlinson]

I see in the process that there is the following :

Post Release
Within 3 days of the release, the release lead and release shadow are responsible for;

Facilitating a 1-hour community meeting to evaluate the release. This discussion should cover:
What worked well for this release.
What could be improved for the next release.
Update the release documentation and processes to capture improvements.

Where does this community meeting usually take place? "community" implies it's open to all? Who is allowed to contribute to that meeting? Is it only maintainers? etc

Is there an online journal / record of discussion points, outcomes & actions?

[WhitWaldo]

I'd like to propose two enhancements to the referenced documentation and our release process that I believe could significantly improve the developer experience and overall release quality. I share these thoughts with the hope of fostering a productive discussion around these ideas.

Introduce a "Protos Feeze" Period Prior to Code Freeze

I strongly recommend we consider introducing a "protos freeze" a few weeks ahead of the code freeze. After this point, proto changes would only be made by rare exception.

Here at the end of the 1.16 release cycle, we are seeing active development on the runtime continue will into the code freeze, including changes to the external protos. This create a challenge for me and the other SDK contributors who are left without a stable view of the protos while trying to prepare our repositories for release. As a result, while we're hoping to schedule runtime release candidates imminently, the SDKs are effectively blocked from doing the same.

Given that external protos define the public contract of the runtime, it seems logical to finalize these interfaces early. In my experience across several software organizations, we typically define and lock interfaces first, then build implementations to match. Could we adopt a similar approach here?

By front-loading the design discussions, proposal iterations and community feedback, we can lock down the protos early. This would empower SDK and documentation contributors to work in parallel with runtime development, leading to a more coordinated and timely release process. It would also allow us to honor the code freeze by focusing on stabilization and bug fixes, rather than last-minute feature additions.

I sincerely encourage the Dapr team to consider this approach for the 1.17 and later releases, as I believe it will help us to avoid these last-minute rushes and improve the overall quality and predictability of our releases.

Align SDK Releases with Runtime Releases

I also propose that we aim to release SDKs on the same day as the runtime with full proto parity support.

When SDKs lag behind the runtime at the end of the development cycle, it undermines the purpose of release candidates. Developers cannot fully validate the new release in their environments if the SDKs aren't ready alongside the runtime. In this current 1.16 release cycle, SDK contributors may very well not see the final shape of the conversation protos until just before release, which introduces unnecessary risk and confusion.

Here are a few reasons why I believe this alignment is important:

• Developers typically update both the runtime and SDK together. If the SDK isn't compatible, they may encounter confusing errors due to mismatched protos.
• This applies equally to alpha and stable APIs. Even if an API is marked as alpha, developers still expect the latest release of the SDK to properly interact with the current state of the runtime.
• While some may take the position that developers can fall back to the raw HTTP or gRPC APIs, this undermines the value of our SDKs. If we expect developers to rely on SDKs for a better experience, we need to ensure those SDKs are in sync with the runtime.

Josh mentioned the idea of proto versioning to help mitigate compatibility issues. While that could be a valuable enhancement, I believe it complements rather than replaces the need for synchronized releases.

I appreciate the opportunity to contribute to this discussion and welcome any differing perspectives. My goal is to help us all deliver the best possible experience to both ourselves as maintainers and to our end users, and I look forward to hearing others' thoughts on these suggestions as well.

[olitomlinson]

Developers typically update both the runtime and SDK together. If the SDK isn't compatible, they may encounter confusing errors due to mismatched protos.

I don't think this is true in the wild. Developers typically are not in charge of when the runtime updates in the infra.

Maybe in a greenfield project where there is an initial effort to start a fresh with the latest runtime and most up to date SDK. I would agree.

But after that point, teams will not stay on top of upgrading the SDK.

The whole point of Microservices ownership model is that each team decides when its time to upgrade their dependencies, such as SDKs and Client Libraries they use. If Dapr was to mandate that everyone upgraded the SDKs at the same time as the runtime version, there would be carnage from a management & planning perspective.

This is why the backwards compatibility of the runtime and SDKs is essential.

https://docs.dapr.io/operations/support/support-release-policy/#sdk-compatibility

[WhitWaldo]

My earlier comment should be considered obsolete and no longer reflects my current thinking. I've spent the week thinking about this and have drafted a much longer proposal taking @olitomlinson 's feedback into consideration which is available for review here.