Drop support for .NET Framework 4.6

[JamieMagee]

Currently Octokit targets netstandard2.0 and net46:

octokit.net/Octokit/Octokit.csproj

Line 9 in 73b7a7a

<TargetFrameworks>netstandard2.0;net46</TargetFrameworks>

.NET Framework 4.6 (and 4.6.1) went out of support on April 26 2022¹. Continuing to publish Octokit for this target adds additional support burden.

.NET standard 2.0 covers .NET Framework 4.6.2 already².

Supporting a single target framework, .NET standard 2.0, would simplify maintenance of this project while still supporting all target frameworks that are currently supported upstream.

Footnotes

1. https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-framework ↩

2. https://docs.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0 ↩

[eriawan]

I agree. We should remove support for .NET Framework before v4.7, to be in sync with .NET Framework lifecycle and related Windows support due to tight relationship of .NET Framework and Windows release cycle.

[nickfloyd]

I agree with this 💯. I'd like to get this done sooner than later. I've also marked this as a breaking change - since technically older applications will not be able to use the new version.

My only hesitation (which might not be valid at all) is that we are moving toward SDK generation soon with this SDK. This also means abstracting the models into a separate package so that this type of thing won't matter in the future.

I am thinking about consumers who have pre .NET Standard 2.0 apps - if we made this move after getting generation in place, they would benefit from the current API set before we move forward.

The real question is, when would we be able to get generation done, and does it make sense to wait for it? While generation is not impossible(especially now that GitHub is shipping OpenAPI descriptions), generation is now even more achievable than it ever has been but there are still fringe challenges that might get in the way.

The question is: Which provides more value, removing legacy .NET support first or building generation, updating the models and then shipping that before we remove legacy support.

I'd love to hear yall's thoughts on this - I could easily be overthinking this.

cc: @timrogers @JonruAlveus

[JonruAlveus]

I too believe we should move up to Standard2. It opens up a whole world of new things (and challenges). We can look into different serialisers, newer code styles etc. But, as you say, what do we do with our legacy application users. I feel like we have a couple of options:

• Fork the Repo and maintain 2 versions - net46 and net standard 2. I think avoid multi targeting, that just makes life difficult. When we move to auto generation we could generate to two different repos at different versions. Obviously this is the most work overall
• Drop 46 now and abandon updates for these users. Not ideal but sometimes you just have to move on.
• Complete the manual version and drop 46 later when we have auto generation
• Go full nuclear and move to net6 now 😆

Personally I don’t think we can just drop our users with the api in its current state. I can see requests coming in for features we just can’t give them. I wonder if option 1 (or a variation of it) is the way to go?

[JamieMagee]

I would go with the simplest approach and drop support for .NET 4.6.0 now, before moving onto SDK generation.

Yes, we'd be dropping support for current users that are targeting 4.6.0, but .NET Standard 2.0 already covers .NET Framework 4.6.1 and 4.6.2. I would hope that most users are off .NET Framework 4.6.0, and if not, bumping to .NET Framework 4.6.1 (or 4.6.2) should be a backwards compatible change.

Also, to give you an idea of the release dates¹:

• .NET Framework 4.6.0 20 July 2015
• .NET Framework 4.6.1 30 November 2015
• .NET Framework 4.6.2 2 August 2016

4.6.0 was only available for 4 months before being superseded by 4.6.1.

Also, to compare with the other Octokit libraries:

• octokit.js supports Node.js 14 (or higher) from 31st July 2020²
• octokit.rb support Ruby 2.7 (or higher) from 25th December 2019³

octokit.net is by far the outlier here.

Footnotes

1. https://en.wikipedia.org/wiki/.NET_Framework_version_history#.NET_Framework_4.6 ↩

2. https://github.com/octokit/octokit.js/releases/tag/v2.0.0 ↩

3. https://github.com/octokit/octokit.rb/releases/tag/v5.0.0 ↩

[nickfloyd]

@JamieMagee @JonruAlveus such great perspective. We should move forward on this. I'll prioritize this over a few other things currently in flight unless someone else wants / can pick this up.

Let's drop support for 4.6.0 like you said and move on from there. Thanks for all of the discussion, thoughts, and getting this conversation started.