Add dotnetup preview release-strategy-plan.md#54735
Conversation
This is a draft. Resolves dotnet#54689
or that it might not be the right choice for our product/org even if its the convenient / right choice for our team
- Appendix A: Empirical HTTP probes show no TTL-based deletion on ci.dot.net/dotnetbuilds; 404s are from promotion-cleanup only. Non-promoted builds (like dotnetup) persist 4+ years. No retention policy documented in arcade or dnceng. - Appendix B: Document 5 teams with automated GitHub Releases (aspire, dotnet-monitor, android-native-tools, cli/cli, mcp). List compliance requirements and recommend dotnet-monitor pattern (gh release create + ManualValidation@1) as simplest for Phase 1. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
this might be helpful for an agent to plan but it is not helpful as documentation
There was a problem hiding this comment.
Pull request overview
Adds a design document under documentation/general/dotnetup/designs/ describing a proposed preview release strategy for dotnetup, motivated by the need to decouple SDK branch stability from the dotnetup daily build while still enabling rollback and historical acquisition.
Changes:
- Introduces a phased plan for
dotnetupchannel/version/release promotion (daily→ blessedpreview→ eventualstable). - Documents requirements/assumptions and compares approaches used by other tooling (e.g., Aspire).
- Adds appendices summarizing retention observations for
ci.dot.net/dotnetbuildsand precedent for automated GitHub Releases compliance.
|
|
||
| ### Decisions: preview / phase 1 | ||
|
|
||
| **Must have** |
There was a problem hiding this comment.
I don't know where this should go in terms of priority but I think a requirement is having a good UX around how to report issues. Nothing is more frustrating than getting a new version of a component and discover a crash and then not know where/how to report the issue.
There was a problem hiding this comment.
I agree with you there, and it'd be nice if there was a 'report an issue' function that also auto-injected the build/version of dotnetup, although I'm not sure if this is the right document to include this.
I think this is adjacent but it'd be more clear to put this in a 'bug/triage' type of plan document than here, but for now I'll briefly mention it.
…ase of recovery 15 minutes : decided based on the time it generally takes to currently run tests in ci and to minimize impact. Somewhat arbitrary. We might not run tests in some cases.
nagilson
left a comment
nagilson
left a comment
There was a problem hiding this comment.
Changes needed:
Show that we can repromote a build and that is how arcade supports the release. There is no reasonable way currently to 'swap' the aka url owned by arcade and we can't own their secrets.
Also include how we will manage runtime updates since we are self contained.
Also need to include that the install scripts themselves are shipped and need the versioning schema.
This document provides a plan to address the following:
dotnetupdotnetuprollouts with a focus on thepreviewphasePlease consider giving broad feedback or feedback about my 'requirements' and 'assumptions' to see whether this is a solid foundational idea or not before we get into more specifics.
Resolves #54689