From 5a82b7b605ffbe5da2e34791a202ea0928fe5d2b Mon Sep 17 00:00:00 2001 From: Whit Waldo Date: Tue, 23 Sep 2025 12:54:21 -0500 Subject: [PATCH 1/2] Initial proposal to lock protos early. Signed-off-by: Whit Waldo --- 20250923-RS-development-lifecycle.md | 59 ++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 20250923-RS-development-lifecycle.md diff --git a/20250923-RS-development-lifecycle.md b/20250923-RS-development-lifecycle.md new file mode 100644 index 0000000..6f95c2b --- /dev/null +++ b/20250923-RS-development-lifecycle.md @@ -0,0 +1,59 @@ +# Modify Release Process +- Author: Whit Waldo (@whitwaldo) +- Status: Proposed +- Introduced: 9/23/2025 + +## Overview +Dapr's [release milestone](https://github.com/dapr/community/blob/master/release-process.md#release-milestone) today +calls for three phases in a 13-week (3-month) period: +- Feature definition (~2 weeks) +- Feature implementation and bug fixing (~9 weeks) + - Code freeze happens ~7 weeks into this implementation phase +- Stabilization & release (~2 weeks) + +Today, the prototypes for any given feature are released only at the end of the feature implementation cycle. If the goal +is to then release the new version of Dapr after a 2-week stabilization period, the runtime team then has two weeks to:: +- Write the runtime documentation describing the feature +- Stabilize the functionality and prepare for release. + +But suddenly things get really busy for the SDK maintainers (and I do mean the maintainers: there is not enough time +for the average contributor to help) to: +- Update the SDKs to accommodate changes to existing prototypes (even without adding new features) +- Design and add new functionality (e.g., what should the SDK API look like to effectively implement the new feature?) +- Write SDK feature documentation +- Develop examples of using the new feature with the SDK +- Write and update quickstarts that feature using the new SDK functionality + +So where the runtime team has 13 weeks to iterate on new functionality, this becomes a real time-crunch for the SDK +maintainers to accommodate in only 2 to 4 weeks. It's even worse when you consider that there are often multiple features +in each Dapr release and there is often only one maintainer (and precious few active contributors) for each of the SDKs. +All of these release features often come out at once and put a significant strain on the SDK maintainers to +accommodate to the high bar of quality and stability they would otherwise strive for. + +## Proposal +I propose a shift in the feature design process to be more aligned with common software development practices. Following +feature definition, the feature authors should produce a design document to GitHub that describes the feature and the +prototypes that comprise its API (changes to existing prototypes and new definitions). Following any discussion by other +runtime and SDK maintainers to clarify the approach, it should be generally approved by relevant parties and locked +for the remainder of the release (e.g., a "protos freeze"). + +At this point, work can proceed asynchronously across many different parties: +- Each SDK has plenty of time to design, implement and test the feature, and add examples and documentation +- Global documentation can be developed and iterated on that describe the feature, its purpose, what it solves and how +it works alongside other capabilities + +And finally, at the end of the release cycle, while we're all working on stabilization and producing release candidate +builds, the SDKs can also release RCs, the quickstarts can be updated to target each RC and we can all have a far more +relaxing end to the release. + +I propose that this design document be either a part of the original proposal in `dapr/proposals` or should be in a +separate directory within `dapr/proposals` so all the original thinking around feature design can be readily retained +in one place. + +## Final Thoughts +It's critical that when the prototypes are frozen, they're truly locked. The rest of the Dapr project will be relying +on the shape of the prototypes not to change any more in this release. Should additional changes be needed (as they +regularly will), they should be done in a separate and future release. + +I think this would contribute significantly to a smoother and more timely release cycle for all maintainers and +contributors of Dapr as a whole. \ No newline at end of file From 58b3b76d256d290b11c301d2ce9a8480b56ff353 Mon Sep 17 00:00:00 2001 From: Whit Waldo Date: Tue, 23 Sep 2025 13:44:34 -0500 Subject: [PATCH 2/2] Removed extraneous colon Signed-off-by: Whit Waldo --- 20250923-RS-development-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/20250923-RS-development-lifecycle.md b/20250923-RS-development-lifecycle.md index 6f95c2b..da06e60 100644 --- a/20250923-RS-development-lifecycle.md +++ b/20250923-RS-development-lifecycle.md @@ -12,7 +12,7 @@ calls for three phases in a 13-week (3-month) period: - Stabilization & release (~2 weeks) Today, the prototypes for any given feature are released only at the end of the feature implementation cycle. If the goal -is to then release the new version of Dapr after a 2-week stabilization period, the runtime team then has two weeks to:: +is to then release the new version of Dapr after a 2-week stabilization period, the runtime team then has two weeks to: - Write the runtime documentation describing the feature - Stabilize the functionality and prepare for release.