@Nick_Craver @shanselman @mayankdotnet a few things to consider:
2.1 is 15 months through it's 3 year support lifecycle. That means it certainly has had a bunch of fixes to make it more "stable", but of course those are all in 3.0 too :)
2.1 is 15 months through it's 3 year support lifecycle. That means it certainly has had a bunch of fixes to make it more "stable", but of course those are all in 3.0 too :)
@Nick_Craver @shanselman @mayankdotnet 3.1 will be out shortly (Dec) and will be LTS, giving a fresh 3 year support term. Moving from 3.0 to 3.1 should be trivial.
@Nick_Craver @shanselman @mayankdotnet 3.0 of course has new features that can introduce instability, but it was by far the highest used version during previews we've ever had, and is the fastest adopted version of .NET Core ever by a huge margin. We haven't had to issue a patch due to stability problems so far
@Nick_Craver @shanselman @mayankdotnet If this is a new adoption of .NET Core, and the team is still very risk averse, you could consider multi-targeting 2.1 and 3.0, either via multiple TFMs or multiple projects and linked files. Stick with using 2.1 APIs and you'll be able to run on 3.0 too.
@Nick_Craver @shanselman @mayankdotnet Then if you hit an issue, you can just redeploy it on 2.1. This is pretty extreme, but is doable and might be an option if the team feels it needs that mitigation. Here's an example of a simple #aspnetcore app that can run on .NET Framework, 4.6+ .NET Core 2.x, or 3.x
