Feature-Driven Releases & API Versioning #87
Conversation
Signed-off-by: Whit Waldo <[email protected]>
Co-authored-by: Rob Landers <[email protected]> Signed-off-by: Whit Waldo <[email protected]>
| approach. | ||
|
|
||
| ### 2. Use Semantic Versioning for APIs | ||
| - Eliminate the current `alpha`, `beta`, and `stable` labels for APIs and instead adopt semantic versioning for each |
There was a problem hiding this comment.
how would you forsee this impacting component statuses of alpha, beta, stable?
There was a problem hiding this comment.
I propose eliminating them and replacing with semantic versioning. Beta doesn't ever seem to be used as we're in this rush to indicate a "stable" API (in shape, not necessarily in platform stability) and then when new endpoints are added to stable APIs, they're sort of in this weird flux of not really being stable (since it just changed) but we also don't move a stable API back to alpha, so it really doesn't work well.
As I indicate in the document, by opting to instead use semantic versioning, we can hold ourselves to a position where we release an API as 1.0 when we're happy with an initial release. Additive methods simply iterate the minor version (as they don't break existing implementations that aren't aware of the new methods) and if we must change an existing endpoint or remove it, that constitutes a new major version. But as semantic versioning is otherwise very well understood by the developer community, this eliminates the vagueness of our existing API lifecycle, allows us to keep incrementally iterating on the APIs as needed and doesn't lock us into getting stuck with an API that could have been better designed just because "well, it's the one we declare stable, so we have to stick with it".
In terms of immediate effects, I would replace all stable APIs with a v2.0 version and all APIs in alpha and beta with v0.1 and iterate from there as much as necessary.
There was a problem hiding this comment.
gotcha - makes sense and i agree! any reason for a v2.0 instead of v1.0 for stable?
There was a problem hiding this comment.
Mainly just to have a clear distinction in the versioning between what we use today and the new versioning. Most everything in Dapr is marked as v1 with some lifecycle tag, e.g. "v1-alpha", so by jumping to v2.0, it's more symbolic that the major change is that the entire versioning scheme is being overhauled at this point.
|
I support this Proposal 100% |
Signed-off-by: Whit Waldo <[email protected]>
Following our discussion during last week's release call regarding the synchronization challenges between the runtime and SDKs - and in light of broader observations about our current release philosophy - I'm submitting this proposal for consideration.
It outlines a shift towards feature-driven releases and semantic versioning for APIs, with the goal of improving coordination, reducing release pressure, and enhancing the overall developer experience.
Feedback is welcome, and I've love to see us move on this ahead of 1.17 planning - or, perhaps more fittingly, following adoption of this where there's no longer such a thing as "1.17 planning", just a thoughtful selection of proposals we're ready to move forward with on an ongoing basis.