Updating features proposal after latest discussions.

[Edmundo Gonzalez (edgonmsft)]

Chuck Lantz (@Chuxel), Christof Marti (@chrmarti), Alexandru Dima (@alexdima), John Keech (@jkeech), joshspicer, Samruddhi Khandale (@samruddhikhandale)

closes#43

[joshspicer]

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)

[Christof Marti (chrmarti)]

Can we move install.app and install.file to a separate proposal? I think this requires more discussion. (Previously discussed in #27 (review).)

[Chuck Lantz (Chuxel)]

Already mentioned elsewhere, but adding here for tracking. I think we should call out customizations being in the schema and the expected behavior for merging properties under it. (For example, each "namespace" under customizations is treated as a separate set of properties. For each set, the object is parsed and leaf values are replaced while leaf arrays are a union).

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.

[Chuck Lantz (Chuxel)]

Edmundo Gonzalez (@edgonmsft)Christof Marti (@chrmarti)joshspicerCraig Peters (@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

"architectures": [ "x86_64", "arm64"],
"os": "linux",
"version": {
"debian": ["10", "11"],
"ubuntu": ["20.04", "18.04"],
"alpine": true
}

...where "true" means any version.

[Edmundo Gonzalez (edgonmsft)]

Made changes for the comments here. We can use this issue to track changes for architecture.

#58

[Edmundo Gonzalez (edgonmsft)]

Also: #59