-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating features proposal after latest discussions. #48
Conversation
does it make sense to add an example to installation order, like how I did in the issue? Or too in the weeds? #43 (comment) |
Co-authored-by: Josh Spicer <josh@joshspicer.com> Co-authored-by: Samruddhi Khandale <skhandale@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move install.app and install.file to a separate proposal? I think this requires more discussion. (Previously discussed in #27 (review).)
Co-authored-by: Brigit Murtaugh <brigit.murtaugh@microsoft.com>
Already mentioned elsewhere, but adding here for tracking. I think we should call out I wouldn't want the spec to have to update as new tools come in, for example. Right now there's "extensions" and "settings" at the wrong level per #1. |
@edgonmsft @chrmarti @joshspicer @craiglpeters One other thought. I think at one point we'd discussed the idea that a feature could declare the operating systems and architectures it supports. Given the number of hiccups we've seen with arm64 installs with existing features and PRs like microsoft/vscode-dev-containers#1513 (for Gentoo) driving things into different base OS distros, I think it may be a good idea to include this in the spec from the beginning. Didn't we have that included at one point? We could have normalized architecture values and then support for /etc/os-release detection based on ID or ID_LIKE for distribution. We can also detect the version in a similar way. Most of the features have some code in them to detect and block based on these values. Moving it into the core spec just makes things easier for feature authors and we can provide UX hints if a feature isn't expected to work given the current environment. e.g., something like this might work
...where "true" means any version. |
Made changes for the comments here. We can use this issue to track changes for architecture. |
Also: #59 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review
@Chuxel, @chrmarti, @alexdima, @jkeech, @joshspicer, @samruddhikhandale
closes #43