You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, buildpacks integrate new versions of .NET only after they have GAd. This creates a significant gap between new versions of .NET being available to the general public and availability of buildpacks that include said versions. Coupled with the fact that companies need time to confirm their code is compatible with new buildpacks before upgrading their code and relatively short deprecation cycle of non LTS .net release creates an unreasonable delay for companies looking to switch to new version. This is amplified by a relatively short deprecation cycle of non LTS releases of .NET.
Customers are also looking to start testing their code against upcoming versions of .NET before it GAs, which is impossible today given that buildpacks do not include pre-release versions. With .NET 6 this problem was even further highlighted as .NET beta builds came with a go-live license, meaning that they were supported even without being GA.
Ways to fix this issue:
Create pre-release builds of buildpack. Requires introducing branching and different builds to the overall workflow
Include pre-release versions of .NET into the buildpack, but require their activation explicitly by setting SDK via global.json.
The text was updated successfully, but these errors were encountered:
Thank you for your interest in the Buildpack. Currently, this functionality is not in our immediate scope but this will be discussed with the team, thanks!
@macsux for .NET 7, we used the pre-release to work out all the issues so we could release the updated .NET buildpack the day 7 was GA. Did that work for you?
Currently, buildpacks integrate new versions of .NET only after they have GAd. This creates a significant gap between new versions of .NET being available to the general public and availability of buildpacks that include said versions. Coupled with the fact that companies need time to confirm their code is compatible with new buildpacks before upgrading their code and relatively short deprecation cycle of non LTS .net release creates an unreasonable delay for companies looking to switch to new version. This is amplified by a relatively short deprecation cycle of non LTS releases of .NET.
Customers are also looking to start testing their code against upcoming versions of .NET before it GAs, which is impossible today given that buildpacks do not include pre-release versions. With .NET 6 this problem was even further highlighted as .NET beta builds came with a go-live license, meaning that they were supported even without being GA.
Ways to fix this issue:
The text was updated successfully, but these errors were encountered: