testing/dotnet8: supporting newer feature bands
Per https://github.com/dotnet/source-build/discussions/3524, starting with dotnet8, building from source newer feature bands will be supported. Intuitively, this means that rather than being stuck on 8.0.1xx
forever (like we are with dotnet6
and dotnet7
), we could upgrade to 8.0.2xx
once that gets released.
Unfortunately, it is not so intuitive, as:
- only
8.0.1xx
branch will build runtime - all SDK feature branches rely on the same runtime - runtime build will want
8.0.1xx
sdk - thus we can't just ditch that sdk feature band when a newer one is released -
8.0.2xx
will likely want8.0.1xx
sdk as well - but not forever
I find this confusing from a maintenance perspective, and I'm kind of cursing Microsoft for such an odd feature release cycle, exacerbating an already convoluted build process. But whatever - you deal with what life gives you. That said, I'm opening this space to discuss how the community would like me to proceed.
I see two approaches:
- Stay on the
8.0.1xx
branch forever - keeping withdotnet7
anddotnet6
- Follow latest feature band - building dotnet8's sdk components twice on every update
For the second approach, a workflow I can imagine is decoupling build of runtime and sdk. dotnet8-runtime
aport would always build 8.0.1xx
branch, packaging the runtime and sdk of that version. dotnet8-sdk
aport would build the latest sdk feature band using dotnet8-runtime
and dotnet8-sdk~=8.0.1xx
provided by dotnet8-runtime
aport.
The first approach is obviously the simplest one, but indeed I've had a few requests to upgrade dotnet7
to the latest feature band, and so I can only imagine that the ideal (from a user perspective) is the second approach. On the other hand, it represents more maintenance resources. Already, we pulled mono-based dotnet support (thus axing s390x
and ppc64le
) due to the resource overhead. From a build infra perspective, a lot of CPU cycles would be used just to keep dotnet up to date. Infra's perspective is thus valuable in this case. That said, a mitigating factor is that 30-40% of the build time is dedicated to runtime, which we would only build once.