@mairaw can we test this for dot.net to ensure this doesn’t break it?

We know that this change will break the website (mostly due to the same issue as #7497). @mairaw would like to test this change, as you suggest, to see if there are other issues.

If we have other known contacts who use these files, now would be a good time to contact them.

The new property doesn't cause any issues on our ingestion process. And I just created a PR to not rely on eol-date being null to determine support phase, which can be merged today. With that change merged, we could even add the .NET 7 EOL dates back in.

With that change merged, we could even add the .NET 7 EOL dates back in.

This PR does that. We can wait to merge this PR or unrevert the other one. Might as well wait and then we can tell people about the changes all at once.

Yep, either way is fine.

I'll leave that up to you. Whichever approach you prefer.

Are you planning on adding the release-type to older releases.json files, e.g. 1.0 or 2.2? If not, what should be the default value when reading these files for the property? We have use cases for processing these files and I want to make sure the releases API handles this in a consistent fashion. I could also consider an undefined enum.

I updated all the release objects in release-index.json. I didn't update the old release.json files in absence of a reason to do so. If you have a scenario where that would be helpful, I'm willing to do it. It won't take me very long. Should I?

I updated all the release objects in release-index.json. I didn't update the old release.json files in absence of a reason to do so. If you have a scenario where that would be helpful, I'm willing to do it. It won't take me very long. Should I?

That would be great, unless you have a suggestion for assigning a default value when the release-type is absent in the JSON - I'd be open to that as well.

I'll start working on the PR for the website now. @richlander do you want to handle the merge conflicts here?

Happy to deal with the merge conflicts. However, I think I promised that I wouldn't merge these files until 7/13 (or some similar date). I'd rather wait until July patch Tuesday. Fair?

Of course, no problem!

I just dealt with the merge conflicts since I also had to add the missing property to all other versions. And when would we add the changes to the support-phase property? I just need to account for the interim solution with the current values.

Thank @mairaw!

Do we have tests or any validation for install scripts? There are args that expect Channel that will now be changing (https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script#options)

now changing

I assume you mean "not changing"

Current - Most current release.

Looks like that can still be satisfied w/o issue. I'm not sure if what it says is what it does. Good question.

Maybe @YuliiaKovalova and @dotnet/install-scripts-maintainers can tell us.

Yes @richlander I'm thinking to make sure things like -Channel sts would be expected to work...I think it will work based on my 2m reading of the code, but might need to just expand test validation/coverage of adding the new labels.

As I understand it, the label Current works as expected with install scripts (installs .NET 6.0) while it undesirably refers to 5.0 in VS.

@richlander already mentioned that this will be a breaking change, but I wanted to double check that we are on the same page about what exactly will be broken. So, here are some questions that popped into my head:

1. Does removal of Current label also mean the removal of Current channel? @mmitche @adiaaida
2. Current allows the users of install scripts to say "give me whatever is the latest GA version, whether it is LTS or not" which (warning: speculation ahead!) may be a common scenario for people wanting to stay up to date (end of speculation). If the channel Current will indeed be removed, can we say that "this is one of the breaking changes we are introducing"? What alternative can we offer for these users?
3. As we are updating install scripts documentation, do we want to add sts to the list of supported channels? Agreeing with @richlander above, it may be an anti-pattern since from the context of the scripts it will mean "give me the latest GA build, but make sure it is one of those that will expire soon".
   I'm unsure whether the benefits of having an sts channel in scripts will worth the maintenance costs as well as the potential user confusion.

1. Does removal of Current label also mean the removal of Current channel? @mmitche @adiaaida

Current in terms of the concept that users can dotnet-install --version current (ie, the aka.ms links) seem like they would be unaffected by this change. Creating the current links is a manually run pipeline that we do once a release (more or less on GA release day).

I'm unsure whether the benefits of having an sts channel in scripts will worth the maintenance costs as well as the potential user confusion.

If we add sts to dotnet-install we will need to update a bunch of stuff in other places. Please ping me if we decide to do this.

Let's just stay as-is. I will write up some docs and probably a blog post on our updated approach. I will review it with you folks to ensure everything is correct.

We could change "Current" to "Latest" but that seems like a lot of churn for little benefit. I am NOT proposing that.

@jamshedd I resolved all the comments because changing those is no longer the plan of record. Please review again.

These changes should be included with all other releases.json changes for GA. We won't be able to handle different changes coming at different PRs for the website (or we'll need to skip some deployments).