.NET release schedule

[monkeyman192]

MBINCompiler will follow the following schedule for the version of .NET that it will be built with.
This will be influenced by the dates that new .NET versions are released and old ones are deprecated as per endoflife.date.

Current "Main" .NET version: 8
Current "Fallback" .NET version: 6

When a new LTS version is released, the "Fallback" version will be changed to that until the current "Main" version becomes EOL, at which point the "Main" version and "Fallback" versions will swap.

MBINCompiler will always use the oldest possible SDK version for the given runtime version to ensure maximum compatibility.

[Kobi-Blade]

I hope you don’t mind me pointing this out, but since SDKs don’t introduce breaking changes within a given runtime, sticking to the oldest SDK doesn’t actually improve compatibility. Instead, it prevents you from benefiting from performance improvements and critical security updates.

This becomes even more important when targeting EOL frameworks like .NET 6, where staying on the latest SDK is one of the few ways to mitigate risks.

I’m also not sure when you plan to move to .NET 10, but I’ve already been using it experimentally without any issues.

[monkeyman192]

I hope you don’t mind me pointing this out, but since SDKs don’t introduce breaking changes within a given runtime, sticking to the oldest SDK doesn’t actually improve compatibility. Instead, it prevents you from benefiting from performance improvements and critical security updates.

This becomes even more important when targeting EOL frameworks like .NET 6, where staying on the latest SDK is one of the few ways to mitigate risks.

I’m also not sure when you plan to move to .NET 10, but I’ve already been using it experimentally without any issues.

Thanks, I appreciate the insight!
I am (clearly) not very well versed with the ins and outs of the .net runtime, so I wasn't aware of this, and this is very useful to know.
My reasoning for doing it was that I think I found that if I had an older version of the runtime (ie. 8.0.X) and built for 8.0.Y where Y > X, then I couldn't run the app unless I had at least 8.0.Y. However by targeting the earliest .net 8 runtime meant that there would be less chances of a user needing to update their version. Ie. We can just say "download the .net 8 runtime", and we can know that whatever they download it will always support the .net build we produce here.
Otherwise if I let it just go with the latest, every so often the CI would pull the latest and then a large number of people would need to again install the latest .net run time, just because the version has been bumped internally.
It just makes the whole process a bit more annoying for end users.
We should be dropping .net 6 and moving to .net 10 around now anyway, I just haven't gotten around to updating the CI.
Good to know there are no issues with it running on .net 10 though 😄