You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Drops redundant sections (When to use, Schema notes, Important distinctions,
Extraction tips) and replaces verbose Process steps with a short outline that
defers to the canonical JSON paths reference. Same guidance, ~34% shorter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
| Official OS support |`release-notes/<version>/supported-os.json`| The only authoritative source for whether a .NET version officially supports an OS or distro release. |
31
-
| Native dependencies, newer schema |`release-notes/<version>/distros/<distro>.json`| Use `releases[].dependencies`. `dotnet-dependencies.md` is a generated view of this data. |
32
-
| Package feed availability, newer schema |`release-notes/<version>/distros/<distro>.json`| Use `dotnet_packages` for the base/built-in distro feed and `dotnet_packages_other` for additional feed-registration options. `dotnet-packages.md` is a generated view of this data. |
33
-
| Native dependencies, legacy schema |`release-notes/<version>/os-packages.json`| Use when the version does not have `distros/` data for that question. `os-packages.md` is a generated view. |
34
-
| Rendered docs |`supported-os.md`, `dotnet-dependencies.md`, `dotnet-packages.md`, `os-packages.md`| Useful for quoting commands, but prefer JSON as the canonical source. |
35
-
36
-
## Schema notes
25
+
| Official support |`release-notes/<v>/supported-os.json`|`families[].distributions[].{supported,unsupported}-versions`|
Currently supported .NET versions share a uniform layout (`supported-os.json` + `distros/<distro>.json`), so most queries reduce to reading the same fields across versions. Older versions may only have `supported-os.json` + legacy `os-packages.json`, which documents native dependencies but **not** package-feed availability.
30
+
The `.md` siblings (`supported-os.md`, `dotnet-packages.md`,
31
+
`dotnet-dependencies.md`, `os-packages.md`) are generated views — useful for
32
+
quoting commands, but JSON is canonical.
39
33
40
34
## Critical rules
41
35
42
-
1. Never infer **official support** from package data.
43
-
2. Never infer **package availability** from `supported-os.json` or `os-packages.json`.
44
-
3. Do not substitute preview/GA status for the documented JSON fields when those fields have a value. Preview/GA status is only a tiebreaker for interpreting null fields (see rule #4).
45
-
4. When `dotnet_packages` and `dotnet_packages_other` are both null, distinguish three cases by cross-checking `releases-index.json` for the channel's `support-phase`:
46
-
-**Preview** channel: report as **not yet available** — packages may land before GA.
47
-
-**Active** (or other GA) channel with current `distros/<distro>.json` data: report as **not available** from the distro package manager.
48
-
-**No `distros/<distro>.json` for that version, or the file predates the distro release**: report as **not documented**.
49
-
5. Quote package names exactly as documented.
50
-
6. When the user asks both support and installation questions, split the answer into **Support**, **Packages**, and **Dependencies**.
36
+
1. Never infer **official support** from package data, or **package
37
+
availability** from support data. A distro release can appear in package
38
+
metadata without being officially supported.
39
+
2. Treat the `supported-os.json` lists as authoritative: a release in
40
+
`supported-versions` is supported, a release in `unsupported-versions`
41
+
(or absent from both) is unsupported.
42
+
3. Do not substitute preview/GA status for documented JSON fields.
43
+
Preview/GA is only a tiebreaker for null fields (rule 4).
44
+
4. When `dotnet_packages` and `dotnet_packages_other` are both null,
45
+
cross-check `releases-index.json``support-phase`:
46
+
-**Preview** channel → **not yet available** (packages may land before
47
+
GA).
48
+
-**Active** (or other GA) channel with current `distros/<distro>.json`
49
+
data → **not available** from the distro package manager.
50
+
-**No `distros/<distro>.json` for that version, or the file predates the
51
+
distro release** → **not documented**.
52
+
5.`dotnet_packages` = built-in/base distro feed.
53
+
`dotnet_packages_other` = extra feed requiring a registration step.
54
+
6. Native dependencies (`libicu`, `libssl`, `libstdc++`, `tzdata`, etc.) are
55
+
OS packages, distinct from .NET packages (`dotnet-sdk-10.0`,
56
+
`aspnetcore-runtime-10.0`).
57
+
7. The distro's `install_command` is only a formatting template for the
58
+
package list — not a .NET package feed command.
59
+
8. Quote package names exactly as documented.
60
+
9. For combined questions, split the answer into **Support**, **Packages**,
61
+
and **Dependencies**.
51
62
52
63
## Process
53
64
54
-
### 1. Classify the query
55
-
56
-
Before reading anything, identify the minimum data needed:
57
-
58
-
-**Support only**
59
-
-**Package-feed availability only**
60
-
-**Native dependencies only**
61
-
-**Combined** support/package/dependency question
62
-
63
-
Also identify the requested scope:
64
-
65
-
- a **specific .NET version**
66
-
- a **set of versions** named by the user
67
-
- the **current supported versions** for a distro or distro release
68
-
69
-
Do not collect package or dependency data for support-only questions, and do not scan every version when the user named one.
-**Package feeds** for supported Linux versions -> `release-notes/<version>/distros/<distro>.json`
75
-
-**Dependencies** for supported Linux versions -> `release-notes/<version>/distros/<distro>.json`
76
-
-**Dependencies** for older versions without `distros/` data -> `release-notes/<version>/os-packages.json`
77
-
78
-
If the user named a single version, go straight to that version's files. Enumerate versions only when the scope is broad or unspecified.
79
-
80
-
### 3. Identify versions in scope
81
-
82
-
For Linux distro questions about supported .NET versions, start with versions that have both `supported-os.json` and `distros/<distro>.json`. That is the default, richest query set. Only fall back to older versions that use `os-packages.json` when the user explicitly asks about older or out-of-support versions, or when the question is dependency-only.
83
-
84
-
Because the current supported versions share the same file layout and keys, prefer direct JSON extraction over broad repo-wide text search. Use discovery only to enumerate candidate version directories if you do not already know them; once you have that list, read or script against the matching JSON files directly.
85
-
86
-
If discovery or text search looks wrong, open representative JSON files directly before concluding the data is absent.
87
-
88
-
### 4. Determine official support
89
-
90
-
For support-only questions, this is the fast path: read the distro entry from each `release-notes/<version>/supported-os.json` and stop there unless the user also asked about package feeds or dependencies.
91
-
92
-
For each version:
93
-
94
-
1. Open `release-notes/<version>/supported-os.json`.
95
-
2. Find the distro or OS entry.
96
-
3. Check whether the requested release appears in `supported-versions` or `unsupported-versions`.
97
-
98
-
Treat that result as authoritative for support status. The absense of a version means "unsupported".
99
-
100
-
### 5. Determine package-feed availability
101
-
102
-
For Linux distro package-manager questions (`apt`, `dnf`, `zypper`, and so on):
-`dotnet_packages` for the base distro feed; treat this as built-in package availability
108
-
-`dotnet_packages_other` for alternative feeds that require a registration step
109
-
4. If both fields are null, apply rule #4 in [Critical rules](#critical-rules): use `releases-index.json``support-phase` to choose between **not yet available** (preview), **not available** (active GA), or **not documented** (stale or missing schema).
110
-
111
-
### 6. Determine native dependencies
112
-
113
-
For manual installs or self-contained deployments:
114
-
115
-
1. Prefer `release-notes/<version>/distros/<distro>.json` and use `dependencies`.
116
-
2. If that schema is not present for the version, fall back to `release-notes/<version>/os-packages.json` and use the distro release's `packages` list.
117
-
3. Use the distro's `install_command` only as a formatting template for the package list; do not confuse it with a .NET package feed command.
118
-
119
-
## Important distinctions
120
-
121
-
### Support vs packages
122
-
123
-
A distro release can appear in package metadata without being officially supported. Answer these separately.
124
-
125
-
### Built-in vs alternative feeds
126
-
127
-
`dotnet_packages` means the packages are available from the distro's base or normal package feeds; treat that as built-in availability. `dotnet_packages_other` means an extra feed-registration step is required before installation.
128
-
129
-
### Dependencies vs .NET packages
130
-
131
-
Native dependencies are OS packages like `libicu`, `libssl`, `libstdc++`, and `tzdata`. They are separate from `.NET` packages like `dotnet-sdk-10.0` or `aspnetcore-runtime-10.0`.
132
-
133
-
## Automation hints
134
-
135
-
Do not add a checked-in helper script just to answer a read-only question. If ad hoc automation helps, write a one-off `jq`, `python3`, or shell snippet locally and discard it after use.
136
-
137
-
Prefer JSON-oriented extraction over `rg`/`grep` when you already know which files and fields you need. Favor a single structured pass that emits only the columns needed for the question rather than collecting a superset "just in case."
138
-
139
-
### Canonical join keys
140
-
141
-
-**Version**: the `release-notes/<version>/` directory name, such as `8.0`, `9.0`, or `10.0`
142
-
-**Distro**: the distro file name and distribution `id`, such as `ubuntu`, `fedora`, or `rhel`
143
-
-**Distro release**: the release string, such as `26.04`, `24.04`, or `9`
144
-
145
-
### Canonical JSON paths
146
-
147
-
- Official support:
148
-
-`families[]`
149
-
-`families[].distributions[]`
150
-
- distro match: `.id == "<distro>"`
151
-
- status fields: `.supported-versions[]` and `.unsupported-versions[]`
152
-
- Newer package/dependency schema:
153
-
-`releases[]`
154
-
- release match: `.release == "<distro-release>"`
65
+
1.**Classify** — support only, packages only, dependencies only, or
66
+
combined; and the version scope (single, named set, or
67
+
current-supported).
68
+
2.**Scope versions** — for current Linux-distro questions, default to
69
+
versions with both `supported-os.json` and `distros/<distro>.json`. Fall
70
+
back to legacy `os-packages.json` only when the user asks about older or
71
+
out-of-support versions, or for dependency-only questions on those
72
+
versions.
73
+
3.**Extract** — read the fields named in [Canonical JSON
74
+
paths](#canonical-json-paths). Stop as soon as the question's facets are
75
+
answered — don't collect a superset.
76
+
77
+
If the user named a single version, go straight to its files; enumerate
78
+
versions only when scope is broad. If discovery or text search looks wrong,
79
+
open a representative JSON file directly before concluding the data is
80
+
absent.
81
+
82
+
## Canonical join keys
83
+
84
+
-**Version** — `release-notes/<version>/` directory name (e.g., `8.0`,
85
+
`10.0`)
86
+
-**Distro** — file name and `id` (e.g., `ubuntu`, `fedora`, `rhel`)
- use the matching distro and release entry in `os-packages.json`
160
-
- package list comes from that release's `packages[]`
99
+
-**Legacy dependency schema** in `os-packages.json`:
100
+
- matching distro and release entry's `packages[]`
161
101
162
-
### Extraction tips
102
+
##Automation
163
103
164
-
- Run one structured `jq` or `python3` pass across the resolved file set; emit one compact row per version with only the fields the user asked for (support, built-in packages, extra-feed packages, dependencies).
165
-
- Stop as soon as all requested facets are answered — do not collect a superset "just in case."
104
+
Don't add a checked-in helper script for read-only questions — use a one-off
105
+
`jq` / `python3` / shell snippet locally and discard. Prefer a single
106
+
structured JSON pass over `rg`/`grep` text scans, emitting only the fields
107
+
needed (one compact row per version).
166
108
167
109
## Output guidance
168
110
169
-
- Lead with the support answer.
170
-
- Then list package-feed availability, distinguishing built-in feeds from extra-feed cases.
171
-
-Then list native dependencies for manual or self-contained scenarios.
172
-
- For multi-version Linux questions, prefer a table. If dependencies are identical across versions, list them once.
173
-
- For single-version or single-facet questions, prefer a short direct answer over a full table.
174
-
- Call out uncertainty explicitly when the repo has incomplete data for a version.
175
-
111
+
- Lead with support, then package-feed availability (built-in vs
112
+
extra-feed), then native dependencies.
113
+
-For multi-version Linux questions, prefer a table; if dependencies are
114
+
identical across versions, list them once.
115
+
- For single-version or single-facet questions, use a short direct answer
116
+
instead of a full table.
117
+
- Call out uncertainty when the repo has incomplete data for a version.
0 commit comments