Request tracks for dotnet-runtime and dotnet-sdk

store-requests
1

Hi folks,

I would like to request the following Tracks for the dotnet-runtime and dotnet-sdk snaps.

lts
2.1
2.2
3.0
3.1
5.0

Let me know if other details are needed.

Lee

2

Hi!

Thanks for requesting tracks. I would like some more information on the requested track names, we typically ask for the same for most track requests.

Do you have any documentation on release schedule/cadence for dotnet? i.e. how long is each legacy track supported, and how often are new releases made, which presumably requires creating a new track for the newly-demoted-to-legacy current release?

Are these versions of the software typically backwards-incompatible? such that e.g. my code targeting 3.1 can’t be compiled with 5.0 and so on? does this also apply for what looks like minor jumps like 2.1 -> 2.1 and 3.0 -> 3.1? (this is in general less of an issue with development tools because some developers are strict about always building with the same version even if the new one is mostly backwards-compatible).

What’s the intent of the “lts” track?

With that information I will be able to make a better decision.

Thanks!

  • Daniel
3

Hi Daniel,

Release roadmap covering the next few years is at https://github.com/dotnet/core/blob/master/roadmap.md.

A 1st principle of our toolset is that the newer versions can always be used to target and build for a previous Runtime version. Also, we have runtime version roll-forward semantics which enable older applications to automatically run against a newer runtime in the event the specifically targeted version is unavailable.

An lts track would enable users to easily stay on lts releases as they become available every other year.

Lee

4

Thanks for replying!

The release roadmap is very clear and the cadence/semantics look like a good use of tracks, so we have that aspect covered.

The target/runtime behavior seem to be such that it wouldn’t be strictly necessary to keep older versions around and selectable via tracks, but I’m not opposed to using tracks to give users an explicit choice, and as mentioned, there is precedent for this kind of use case.

For the lts track - If I’m on the “latest” track, I would get an update every year, while lts are published every 2 years and supported for 3 years, but someone following the lts track would still get auto-updated once the new lts comes out (and the usual pattern we’ve seen is for selection of an lts to be explicit with no auto-upgrading). Also, someone on an lts track is not leveraging one of the 3 years of support offered for lts releases (since they’d get auto-upgraded to the LTS that’s published after 2 years). In general, rolling “lts” is not a usual pattern, and while I’m not opposed to it, I just wanted to make you aware of this.

As is, I’m +1 on creating all these tracks, lts included. Just need to wait a few days for other reviewers to chime in.

Thanks for your explanations and patience!

  • Daniel
5

Thanks Lee for explaining in detail.
+1 from me too!

6

Also :+1: from me.

7

Hello,

I’ve created the requested tracks for dotnet-sdk and dotnet-runtime.

Enjoy!

  • Daniel
1 Like
8

Hey folks,

We’re getting ready to begin releasing previews for .NET 6 so need to have a ‘6.0’ Track added to dotnet-sdk and dotnet-runtime.

Thanks!
Lee

9

Hi! +1 from me as reviewer, and per the simplified process, the track has been created for both snaps.

  • Daniel
10

Awesome - thanks, Daniel.

Lee