Clarify cli acquisition milestones and provide ecosystem context #353
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to make it clear that the public preview phase is still treating the tool as an experiment - we want to collect feedback and data to turn into a "should we make this a fully-supported product" decision through the public preview period. Then, based on that go/no-go decision with management, we have SDL and fit-and-finish requirements to go implement.
rolfbjarne
reviewed
Dec 2, 2025
Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
marcpopMSFT
changed the title
jaredpar
reviewed
Dec 12, 2025
| * **Go and Java:** Language runtimes often installed centrally, but developers increasingly use version managers or user-scoped installs to avoid admin rights. | ||
| * **PATH-based discovery** is universal across ecosystems. | ||
| * **Isolation mechanisms** (virtual environments, local installs) are highly valued for avoiding dependency conflicts. | ||
|
|
Member
There was a problem hiding this comment.
Feel like we need to pick one or two of these and dive deeper. Basically what happens with nvm when there is a global install, how do they recommend it get handled and what is the user experience around it? Think knowing that for a few others helps put into context some of the challenges that we have here.
Member
There was a problem hiding this comment.
I agree - we've done deep dives before but the documentation for that didn't get merged. @/baronfel added a section about nvm and rustup, and I expanded on this in another PR that got merged into this one, detailing nvm and how it inform(s) or compares to the dotnetup concept.
Co-authored-by: baronfel <[email protected]>
…nvm-rustup Expand Ecosystem Context with nvm/rustup deep dives and command comparisons
Move dotnetup proposal from @baronfel into 2026 folder. Doing this in the same commit to cause detection of the new folder
In this PR, I add onto the proposal from @baronfel to include a direct comparison, showing some of what I researched about `nvm` and how we thought about it when designing `dotnetup`. Some of this is pretty specific into technical detail and I want to avoid this document becoming huge and unreviewable. @baronfel's document also is a larger picture sell rather than a dive into the specifics, however I thought it would be helpful to have this information here. We can close these changes if we disagree and move it elsewhere. I tried to briefly touch on the topics without duplicating what will go into `dotnet/sdk/documentation/dotnetup` - the `hive` defaults and `path` handling alone will be their own documents. It can take several pages to explain.
…etup-to-baronfel-spec
More of this is generated text, but I've modified it and done some fact checking.
Co-authored-by: Jan Kotas <[email protected]>
…tup-to-baronfel-spec Add comparison for nvm and dotnetup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We want to make it clear that the public preview phase is still treating the tool as an experiment - we want to collect feedback and data to turn into a "should we make this a fully-supported product" decision through the public preview period.
Then, based on that go/no-go decision with management, we have SDL and fit-and-finish requirements to go implement.
from marcpopMSFT:
Added some ecosystem context that clarifying how other tools work today and what customers are gravitating towards.