`-c STS` is almost meaningless when the latest major release is an LTS (e.g. .NET 8)

[nodakai]

I believe that the -c STS option should consider both STS and LTS releases, rather than focusing exclusively on STS. Alternatively, there could be a different mode that selects the newer version between STS and LTS.

Currently, -c LTS (the default) installs SDK 8.0.100, while -c STS installs 7.0.404. It seems more practical to use -c 8.0 etc. and update the channel IDs once a year, if -c STS does not automatically choose the latest major release channel.

While the current approach might align with the distribution method of release files on Azure CDN, it's not particularly convenient for the script users.

[YuliiaKovalova]

Hi @nodakai,
Thank you for reporting this issue. Let's invite other people to discuss your reasoning.

@leecow & @baronfel please share your opinion on that.
Probably we can improve documentation/review the existing script design.

[leecow]

The desired outcome is reasonable, and I recall discussions early in .NET around STS (then 'Current') and LTS resolving to the same version every other release cycle. I don't have any objections to making the change.

[baronfel]

I'm ok with that change as well - my understanding is that this is more a question of how the STS channel is documented in the help and learn.ms.com docs for this tool, plus some changes to the automated processes that the release team uses to create the redirect scheme for us. Is that correct?

[YuliiaKovalova]

I'm ok with that change as well - my understanding is that this is more a question of how the STS channel is documented in the help and learn.ms.com docs for this tool, plus some changes to the automated processes that the release team uses to create the redirect scheme for us. Is that correct?

You are right. And there is always a chance to download the latest version from the specified channel - it can fill the potential gap for the option absence.

[YuliiaKovalova]

@baronfel, at the same time, the next SDK version is planned to be released as STS
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#cadence:~:text=.-,NET,-release%20cadence
So in a year STS -> .net 9, LTS -> .net 8
@rbhanda, do I miss anything here?

[ArwynFr]

Note there is a 6 months gap between the end of support of LTS-1 and release of LTS+1.
Since may-2024 until nov-24, -c STS installs an unsupported version of the SDK.
This will happen every two years because the STS support is 18 months while the interval between releases is 24 months.
Source: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

I am skeptical of any legitimate use case where the operator's intent is actually to keep the runtime in .NET 7 and upgrade directly to .NET 9 as soon as it is GA, without ever using .NET 8. In my opinion, the 2 common scenarios are to stay on latest supported version or latest LTS version. All other contexts are good candidates to -c A.B. The default value for channel is LTS, so out of the box users only get pair versions. Even if you retain the current behavior with better documentation, there should be an option to install the latest currently supported version. Perhaps -c Current ?

[baronfel]

-c Current makes good sense to me, and is a thing we should do.

The main problem we'll have is that the current data sources for the scripts have no concept of support status. To property implement this we'd need to implement #463 so we can use the support information from the release manifests.