core icon indicating copy to clipboard operation
core copied to clipboard
verified publisher icon dotnet

Provide lifecycle information about the SDK

Open richlander opened this issue 6 months ago • 7 comments

There are simple and good ways to determine which runtimes exist and what there support status. In particular, it is easy to write tools that treat runtime versions as a first class concept. I'm in the process of doing just that. I am realizing that it is very difficult to reason about SDK feature bands in the same way. It is something that I'm going to need to solve for the tool to do the right thing.

There are two key (example) questions:

  • Which SDK feature bands exist for 8.0?
  • Which of those feature bands are actively supported?

For example, should I upgrade to the latest 8.0.2xx build due to a recent runtime CVE or is 8.0.2xx EOL and I need to move to a later feature band? Trolling through releases.json files is not an acceptable answer to that.

SDK feature bands have always been weird. The fact that they are effectively undocumented is contributing to that.

Here's the file that provides a great experience for runtime versions: https://github.com/dotnet/core/blob/main/release-notes/releases-index.json.

richlander avatar Jun 04 '25 03:06 richlander

@Falco20019

richlander avatar Jun 04 '25 03:06 richlander

I would totally support the idea. We only install whatever version we get using the installer based on just the major/channel as we also don't know a lot about feature bands. We just expect the installer to do the right thing. But this is sadly also not giving us any hints about EOL.

Falco20019 avatar Jun 04 '25 07:06 Falco20019

Trolling through releases.json files is not an acceptable answer to that.

Why not? It seems like that JSON is where this EOL information should go.

mthalman avatar Jun 04 '25 12:06 mthalman

Trolling through releases.json files is not an acceptable answer to that.

Why not? It seems like that JSON is where this EOL information should go.

You would have to check through all runtimes first to find your SDK as the SDK is child of the release. There is no easy link between SDK and runtime version.

If you want to not add a new file, having a lookup would also be fine for me. With additional information on what the feature band includes. But as they are generated anyway, having the EOL in there should be easy enough.

I would avoid putting feature band information in the existing JSON to avoid more clutter.

Falco20019 avatar Jun 04 '25 13:06 Falco20019

Agree @Falco20019. All that is suggesting,@mthalman, is that SDKs should not be first class. We don't rely on releases.json for this information for runtimes. Also, the releases.json schema doesn't currently have a good spot for this information and it would not be natural to include it.

richlander avatar Jun 04 '25 14:06 richlander

There are simple and good ways to determine which runtimes exist and what there support status. In particular, it is easy to write tools that treat runtime versions as a first class concept. I'm in the process of doing just that. I am realizing that it is very difficult to reason about SDK feature bands in the same way. It is something that I'm going to need to solve for the tool to do the right thing.

There are two key (example) questions:

  • Which SDK feature bands exist for 8.0?
  • Which of those feature bands are actively supported?

For example, should I upgrade to the latest 8.0.2xx build due to a recent runtime CVE or is 8.0.2xx EOL and I need to move to a later feature band? Trolling through releases.json files is not an acceptable answer to that.

SDK feature bands have always been weird. The fact that they are effectively undocumented is contributing to that.

Here's the file that provides a great experience for runtime versions: https://github.com/dotnet/core/blob/main/release-notes/releases-index.json.

Thanks for raising this, Rich — I’ve run into the same challenge when trying to automate tooling that needs to reason about SDK feature bands and their support status. Having a structured, documented source (similar to releases-index.json but with explicit feature band metadata and support timelines) would make it much easier to build reliable tooling and avoid relying on manual parsing of releases.json. If there’s interest, I’d be happy to help draft a proposal or schema for such a document, so it could be maintained alongside the existing release notes.

walid-khalafi avatar Sep 02 '25 20:09 walid-khalafi

Here are two files to look at that I've been (slowly) working on:

  • https://github.com/richlander/core/blob/main/release-notes/8.0/sdk/index.json
  • https://github.com/richlander/core/blob/main/release-notes/archives/index.json

richlander avatar Sep 03 '25 23:09 richlander