Drop unsupported frameworks

[SimonCropp]

Drop

• net462
• netstandard2.0
• netcoreapp3.0
• netcoreapp2.2
• netcoreapp2.1
• net5.0
• netstandard2.1
• netcoreapp3.1

And only support

• net472+
• net6+

[AdrianJSClark]

Technically if you're looking to drop all unsupported frameworks, netcoreapp3.1 should be included as .NET Core 3.1 is out of support as of last December.

[andrewlock]

As someone who needs to support out of date framework versions, I totally get your pain, and understand the need to move forward.

However as we can't drop out of support frameworks, that gives us a hard ceiling of where we can update to, and may mean we need to fork verify longer term or look for alternatives. Not saying you shouldn't do it obviously, just our position.

That said, I think we're way behind on updates as IIRC we ran into too many breaking changes in earlier versions that couldn't be easily resolved (as dependency related) so may never make it up to date anyway 😅

[SeanKilleen]

My personal opinion, though it may be unpopular --

It is the responsibility of downstream software projects to update their frameworks if they want their software to move forward in time. Not undertaking this work is like freezing the project in time; your available options also may be frozen in time.

I think there are 3 categories/themes:

• For some projects, this time capsule is inevitable. Something ships and is considered "done". While I might disagree with that approach, the chances are that in this case the project's libraries can remain relatively the same, as not much is changing.
• For some projects, they are blocked from updating the framework due to some additional dependencies or needs that aren't met (and by this I mean "it doesn't exist" -- not "it's hard" or "it would take a long time"). I think this used to be a larger category but has since gotten much smaller. These projects are unintentionally time-capsuled, maybe through no fault of their own.
• Some projects are perfectly capable of upgrading but do not choose to value it and believe tooling should just work without them doing their part and expect maintainers to shoulder this burden.

The communication challenge comes when projects aren't clear about (or don't know) which bucket they're in.

But regardless -- in my opinion these projects are chaining themselves to a baseline that lives in the past. The implicit trade-off there, IMO, is that these projects don't also get to use the latest and greatest things from the future. I wouldn't be able to get digital audio out of an old sound blaster card; I don't get 4K video from a graphics card that is 10 years old; I don't get to take advantage of multi-threading on a single core CPU. People respect the physical limitations of hardware but don't always translate that into the world of software where it seems like anything should be possible (and is -- if maintainers wreck themselves for it.)

So in summary: do what works for you to help you be productive for those who are on the same timeline as you and not anchored to a past timeline. Maybe they'll move on from your tool, maybe they'll be upset. That's their prerogative. But I hope these points can help you frame that discussion when it comes up.

Side thought: maybe if enough OSS projects can frame the conversation this way, the ecosystem-wide message will be driven home. And for those projects truly stuck in that second box of being unable to move forward, maybe the community or MS can step in in other ways to help them with that.

[stsrki]

I would update the project to v20, as a major version, and then support only .NET 6+.

[SimonCropp]

@AdrianJSClark

Technically if you're looking to drop all unsupported frameworks, netcoreapp3.1

while i would like to. i think some period of grace is fair

[SimonCropp]

@andrewlock

may mean we need to fork verify longer term or look for alternatives

I would really prefer no one need to do this

That said, I think we're way behind on updates as IIRC we ran into too many breaking changes in earlier versions that couldn't be easily resolved (as dependency related) so may never make it up to date anyway

are there any breaking change i need to do a better job of explaining? or writing better upgrade guides? do u need help upgrading? we could jump on a call, or if u need some more dedicated time, i could do a short term contract to do the upgrade for you.

However as we can't drop out of support frameworks,

• What "out of support frameworks" do you target?
• If u target net46x what is stopping u from updating to net472?
• If u target netcore2 what is stopping you from updating to netcore3.1?
• If u target net5 what is stopping you from updating to net6?
• Do u have a timeline for moving off any of those unsupported frameworks?

[SimonCropp]

@stsrki

I would update the project to v20, as a major version, and then support only .NET 6+.

as much as i would like to, i think it is a bit soon. I even work on a project that cant move off net48 because it targets on prem sharepoint

[AdrianJSClark]

@SimonCropp wrote:

while i would like to. i think some period of grace is fair

That's 100% fair. I was being a bit pedantic is all.

[distantcam]

FWIW roslyn libraries (analyzers, source generators etc) are told to use NetStandard 2.0 (https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview#get-started-with-source-generators for example)

This doesn't really affect the test libraries, as they can still be on current frameworks, but still, it's an odd case where MS still recommends using an old target framework.

[bruno-garcia]

This would be bad news for Sentry which has the philosophy 'compatibility is king'. So far we managed to build (since 2018) with net461 and ns2.0 as a baseline, while adding new things. Verify was added (thanks for the contribution Simon) but we certainly can't drop all unsupported tfs because of it. Hope you can consider keeping them for longer.

[AdrianJSClark]

FWIW roslyn libraries (analyzers, source generators etc) are told to use NetStandard 2.0 (https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview#get-started-with-source-generators for example)

This doesn't really affect the test libraries, as they can still be on current frameworks, but still, it's an odd case where MS still recommends using an old target framework.

I think that the reason that netstandard2.0 is recommended is because that's the most recent NetStandard version which .NET Framework 4.7.2 supports and it is still very much a supported framework.

[SimonCropp]

@bruno-garcia

net461 and ns2.0 as a baseline

but do you use Verify with either of those targets?

[duncand]

I have several semi-alternative suggestions:

1. If you're going to support netstandard anything, make it 2.0, because 2.0 is the latest one that's truly significant, because it supports both Framework and Core, while 2.1 does not. I see no good reason for anything to target netstandard at all unless its in order to support Framework plus Core. If you're going to drop Framework support then you might as well just require a net6 minimum instead.

2. Your best option may be to have multiple branches, where the mainline branch has very aggressive requirements, specifically net6+ period and doesn't support anything else, and a legacy LTS branch is just your current version without dropping support for anything you listed, and that branch becomes semi-frozen, getting only critical security and bug fix updates; other stuff only if someone who needs that bankrolls the back-porting of other features.