Replies: 6 comments 25 replies
-
|
As far as Arch Linux is concerned, we will most likely stick to one band, ideally the one that is more advanced/feature-packed (ie more popular/attractive to users). For instance, right now arch users are flagging our current SDK out of date at least once a week, expecting me to push 3xx instead of 1xx. This has become quite annoying over time, so being able to build the 8.0 equivalent of the current 3xx when it comes out would be greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
@tmds What are your expectations around the version of the SDK used to build the shipping runtime? Must it always be up to date (for security or other policies?). Barring bugs, you could theoretically use 8.0.100 to build runtimes forever. |
Beta Was this translation helpful? Give feedback.
-
|
A maintainer will want to use the previous build of the SDK band to build the next. |
Beta Was this translation helpful? Give feedback.
-
|
So that tells me that keeping the 1xx band alongside the runtime, then the 2xx+ bands in separate branches, is the right way to go rather than separating runtime and sdk entirely. This is because you would always need to build the latest 1xx to build the next runtime. While you could probably continue to use an older sdk, it's undesirable, so separating the repos doesn't reduce monthly workload for those only concerned about 2xx. |
Beta Was this translation helpful? Give feedback.
-
|
@alucryd @tmds @omajid This is what I think the build flows would look like: Initial 1xx SDK (no change from today) flowchart LR
bootstrap1xxSDK[MSFT built 8.0.100 SDK]
initial1xxSdkBuild{Build 8.0.100 SDK}
initial1xxSdk[8.0.100 SDK from MSFT SDK]
offline1xxSdkBuild{Build 8.0.100 SDK}
offline1xxSdk[8.0.100 SDK from source-built SDK]
bootstrap1xxSDK-->initial1xxSdkBuild-->initial1xxSdk
initial1xxSdk-->offline1xxSdkBuild-->offline1xxSdk
Month when a 200 band goes RTM. flowchart LR
bootstrap2xxSDK[MSFT-built 8.0.200 SDK]
previouslySB1xxSDK["Previously source-built 8.0.10(N-1) SDK"]
offline1xxSdkBuild{Build 8.0.10N}
offline1xxSdk[8.0.10N SDK from source-built SDK]
initial2xxSdkBuild{Build 8.0.200 SDK}
initial2xxSdk[8.0.200 SDK from MSFT SDK]
offline2xxSdkBuild{Build 8.0.200 SDK}
offline2xxSdk[8.0.200 SDK from source-built SDK]
previouslySB1xxSDK-->offline1xxSdkBuild-->offline1xxSdk
offline1xxSdk-->initial2xxSdkBuild
bootstrap2xxSDK-->initial2xxSdkBuild-->initial2xxSdk
initial2xxSdk-->offline2xxSdkBuild-->offline2xxSdk
offline1xxSdk-->offline2xxSdkBuild
Monthly updates to 1xx and 2xx flowchart LR
previouslySB1xxSDK["Previously source-built 8.0.10(N-1) SDK"]
previouslySB2xxSDK["Previously source-built 8.0.20(N-1) SDK"]
offline1xxSdkBuild{Build 8.0.10N}
offline1xxSdk[8.0.10N SDK from source-built SDK]
offline2xxSdkBuild{Build 8.0.200 SDK}
offline2xxSdk[8.0.200 SDK from source-built SDK]
previouslySB1xxSDK-->offline1xxSdkBuild-->offline1xxSdk
previouslySB2xxSDK-->offline2xxSdkBuild-->offline2xxSdk
offline1xxSdk-->offline2xxSdkBuild
|
Beta Was this translation helpful? Give feedback.
-
|
A couple more possible flows. It's possible that the 1xx SDK will build the 2xx+ SDKs. If the newer SDKs do not take dependencies on their new features, then bootstrapping 200 and monthly updates look the same: flowchart LR
previouslySB1xxSDK["Previously source-built 8.0.10(N-1) SDK"]
offline1xxSdkBuild{Build 8.0.10N}
offline1xxSdk[8.0.10N SDK from source-built SDK]
offline2xxSdkBuild{Build 8.0.200 SDK}
offline2xxSdk[8.0.200 SDK from source-built SDK]
previouslySB1xxSDK-->offline1xxSdkBuild-->offline1xxSdk
previouslySB1xxSDK-->offline2xxSdkBuild-->offline2xxSdk
offline1xxSdk-->offline2xxSdkBuild
|
Beta Was this translation helpful? Give feedback.
-
|
Is there any description of the release/support timelines for each feature band? I understand that 8.0.1xx will be supported for the entire lifetime of 8.0. Is that correct? What about other feature bands? When do they release and how long will they be supported for? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you. I am still unclear on the actual dates that a 8.0.2xx band would be GA'ed and EOL'ed. Are those dates known in advance and public? I also couldn't find a rough date on how long a theoretically 8.0.2xx and 8.0.3xx branch might be supported for (6 months, 12 months, 18 months, etc). This is clearer for 8.0.1xx ("All of .NET 8's lifecycle") but not for these newer SDK feature bands. |
Beta Was this translation helpful? Give feedback.
-
|
8.0.2xx+ bands are tied to Visual Studio releases. The releases dates are not known in advance and public. The lifecycle of these bands is tied to Visual Studio releases. They are supported as long as the Visual Studio versions that they are attached to are supported. For example, https://github.com/dotnet/installer/tree/release/6.0.2xx is no longer maintained for this reason. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Am I reading https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing correctly which suggests that VS release are supported for around 18 months, and so these feature bands would also be supported for around that long? |
Beta Was this translation helpful? Give feedback.
-
That is for LTSC channel. For example, the lifetime 6.0.2xx that was attached to current channel only was much shorter. |
Beta Was this translation helpful? Give feedback.
-
|
This table will help you project out what the lifecycle of the 8.0 feature bands of the SDK will look like: https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs#lifecycle As Jan noted, the feature bands align with Visual Studio versions. While I don't know when 18.0 will ship, I think it's safe to assume that Visual Studio will continue to have quarterly releases which means .NET SDKs will have new feature bands each quarter going from 1xx to 4xx. We support each SDK band for the life of the VS version is ships in (so 18 months for LTSC and 3 months otherwise). We treat 1xx and 4xx special though with 1xx supported for source build customers for the life of the runtime (ie we won't continue to ship the Windows or Microsoft versions once we are past the Visual Studio support cycle for a 1xx version) and 4xx for the life of the matching .NET runtime for all customers (so the highest number feature band is always in support for that runtime). Does that make sense then? |
Beta Was this translation helpful? Give feedback.
-
|
From Alpine Linux's perspective, we'd probably keep our That said, I do share omajid's questions as to N+1. I also wonder about the possibility of decoupling runtime package from the rest of source-build. Since all feature bands share the same runtime, it seems desirable to only build runtime once. |
Beta Was this translation helpful? Give feedback.
-
|
The main issue there is that you need the 1xx SDK to build the runtime. If you want to keep up to date and use the latest 1xx SDKs to build the runtime every month, you would need to build the 1xx SDK every month anyway. Note that from a build time standpoint, the runtime components take most of the time. The runtime is still built only once, just with the 1xx band. Then those outputs would be fed as previously source-built artifacts to the 2xx+ build(s). |
Beta Was this translation helpful? Give feedback.
-
|
Circling back to this, it's unfortunate that runtime will need 1xx SDK to build. I would want to ditch 1xx SDK the second 2xx came out. But alas, supporting 2xx, 3xx, and more also means to keep on supporting 1xx. I find that problematic, and would rather have the option to stay on the latest feature band to build both SDK and runtime. |
Beta Was this translation helpful? Give feedback.
-
|
I had also hoped that would be possible. The limiting factor is the runtime is only maintained to build with the 1xx band. Even if upstream doesn't officially support it, I assume it may work in practice. |
Beta Was this translation helpful? Give feedback.
-
I think it is likely that building the runtime with the 2xx+ SDKs will be functional. Most issues that crop up would be tooling related (new warnings, analyzers). |
Beta Was this translation helpful? Give feedback.
-
|
I've added feedback to the PR, mainly: https://github.com/dotnet/arcade/pull/13720/files#r1238128063. |
Beta Was this translation helpful? Give feedback.
-
|
With my Fedora maintainer hat on, I would be interested in building and releasing the latest feature band for Fedora. The stability provided by the oldest feature band (eg, 8.0.1xx) wouldn't necessarily be beneficial to Fedora, specially if it the older feature bands are not frequently used by users and are harder-to-install. If we are only shipping the latest feature band, the always-required 8.0.1xx build would be a bit wasteful - we would always build 8.0.1xx and then throw it away. If we were to ship multiple SDK versions, I am not sure how upgrade paths should work. In particular, how should the EOL of specific feature bands should be handled. For example, if Fedora was shipping 8.0.1xx, 8.0.2xx, and 8.0.3xx, and we shipped them as separate packages with side-by-side installation, and a user had only 8.0.2xx installed, how should we handle 8.0.2xx EOL? Some options are to leave users running the EOL versions and force-moving users to 8.0.3xx. None of those are both "good" (form a UX point of view) and easy (from a packaging point of view). |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Hi all, happy to see all in the same boat, with similar concerns. This is an excellent opportunity to satisfy Ubuntu's users on their demands about the latest feature bands ("hey, why are you don't shipping x.x.4xx?"). I have questions for different scenarios, also different within the user point of view or the maintainer/packaging one. Sorry in advance if some questions are naive/newbies-kind. The different options we see are:
And, if packaging multiple bands for Ubuntu, then, depending on the release cadence:
From the maintainer's point of view, my questions are:
For deciding on this, we need to take into consideration the user/developer perspective also, so I have this set of questions:
Once those are clarified, deciding what to do will be easier (I hope so!). Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply @mirespace. Let me see if I can cover some of this:
Servicing releases of SDK bands have aligned releases, and the shared runtime components will be identical between them. Let me see if I can explain how it works a bit more in depth. During the development of a major release, the 100 band SDK is also in development and GAs at the same time the runtime does. After GA, we branch off the SDK repos (dotnet/sdk, dotnet/installer, and dotnet/templating) into a 2xx branch where previews are developed and released from. This branch has its shared runtime components set to the previously released runtime, and the input tooling components (e.g. roslyn and nuget) start flowing in from branches that correspond to the upcoming VS release. This new 2xx branch takes tooling changes until the VS point release is ready to GA, at which point it GA's at the same time. Generally this occurs on the normal Tuesday update schedule, so we start flowing the shared runtime components into both the 2xx and 1xx branches in that lead up to the Tuesday update, with the requirement that both 2xx and 1xx ship the exact same set of shared runtime components. This ensures that a user who installs a 2xx SDK sees the same runtime behavior and level of security that a user that installs 1xx, and that a user that installs both 2xx and 1xx side by side doesn't get odd install behavior. Because the runtime installs by default to a shared location, if 2xx and 1xx were to both install, say "8.0.4", but these 8.0.4's were actually not the same product with the same fixes, things would be very confusing as it may be unclear what files actually got laid down on disk. Once on a monthly servicing cadence, all SDK bands currently in servicing release at the same time, dependent on the same runtime.
Yes, or at least it's somewhat likely. The key bit to remember is that the runtime is repackaged in the SDK layout, and all SDK bands released together should have the same shared runtime otherwise in theory a customer could get different behavior deployment an app with a 1xx band SDK vs a 2xx SDK. So, since we need to build the runtime once for all bands and 1xx is used to build that runtime, then we'll need a set of previously source-built components corresponding for building 1xx and the shared runtime. Now, for newer bands you will need a different set of previously source-built components if the newer band requires itself to build. If 2xx requires 2xx to build, then of course you'd need a set of 2xx outputs to build offline. Currently, it is not guaranteed that 2xx requires 2xx, or 3xx requires 3xx. Often only 1xx is required. It is mainly about whether the SDK tooling components (nuget, roslyn, etc.) take dependencies on features that only show up in 2xx during the preview development period. If they decide to do so, then they'll update their SDK to use a new version. Otherwise, the SDK will remain at 1xx. If the SDK required to build 2xx's components stayed at 1xx, then I think you could theoretically use the same set of input previously source-built artifacts. TLDR:
This is not an uncommon scenario. Since global.json can target different versions of the SDK, SxS installations do happen.
We take care to ensure that the functionality of 2xx always includes 1xx. 2xx would include newer tooling, but fixes made to older versions of tooling, and the SDK, that make it into 1xx, should make it into 2xx.
Since the runtime is the same between all of these bands, the SDK has limited power to alter performance in newer bands. Generally, the kinds of features that show up in newer bands are centered around development tooling and not runtime behavior. @jkotas @marcpopMSFT @jaredpar may have some comments on that least bit. |
Beta Was this translation helpful? Give feedback.
-
No. The feature bands are centered around developer tooling and supporting the design time experience in our editors (VS and VS Code). Moving to a higher feature band should not negatively impact the performance of your application. Or said another way, if it did negatively impact the performance of your application it's something we would want to take a look at because most likely that would represent a bug. |
Beta Was this translation helpful? Give feedback.
-
Multiple SDK bands and Source Build
As part of the Unified Build effort on whose status we've recently sent an update, we've already changed how we ship the .NET sources to our various distro partners. Starting with .NET 8.0 previews, we have switched to using a mono-repo (the VMR) for this purpose and we aim to continue using it for .NET 9.0 and beyond.
Once we make .NET 8.0 generally available, we expect to also use the VMR to develop and ship multiple SDK bands (e.g. 8.0.100 and 8.0.200). This is a change from the current situation where only the 100th (.NET 7.0.1xx) band is source-buildable. We aim to bring the Source Build experience on par this way.
Feedback wanted
As this change will have impact on how .NET is consumed by the various distro maintainers, we seek feedback from the community. We have described and analyzed the problematics in a design document for which we have opened a Pull Request. The PR also contains two proposals on how we can implement the solution which are compared.
This is where you come as we're interested in opinions on the following:
Please, have a look at the PR which explains what the SDK bands are, what we plan to do about them and let us know!
cc @dotnet/distro-maintainers
Beta Was this translation helpful? Give feedback.
All reactions