Ocelot to .NET 8 - Githubissues

ThreeMammals / Ocelot

.NET API Gateway

https://www.nuget.org/packages/Ocelot

MIT License

8.32k stars 1.63k forks source link

Ocelot to .NET 8 #1787

Closed ggnaegi closed 10 months ago

ggnaegi commented 10 months ago

Expected Behavior / New Feature

.NET 8 was launched this week, so we expect Ocelot to be compatible with .NET 8 as soon as possible. 😸

Announcing .NET 8 | .NET Blog by Gaurav Seth on November 14th, 2023

Actual Behavior / Motivation for New Feature

Only supporting .NET 7

Specifications

After a chat with @RaynaldM, we should provide .NET8 and .NET7 support for the Ocelot sources (<TargetFrameworks> and Item groups with conditions)
After yet another chat with @raman-m we should provide .NET6 support too...
Tests and examples are targeting .NET8, .NET7 and .NET6 if possible ☕ 🥃 😸

raman-m commented 10 months ago

⚠️⚠️⚠️ ❗Important❗ Feature branch is release/net8. It is created from main. Delivery process is based on Gitflow Hotfix one. That means, this feature (upgrade) should be delivered first, before Oct'23!

raman-m commented 10 months ago

Tests and examples are targeting .NET8

I'm not sure about this. If the lib targets multiple frameworks then why should tests target only one framework?

ggnaegi commented 10 months ago

Ok, let's begin from scratch again, to summarize:

using release/net8 branch
Targeting net6;net7;net8
Updating config, making sure that we are using 2 whitespaces for indent in xml files
Tests and Samples should, if feasible, target to net6;net7 and net8 too 👨🏼‍🚀

raman-m commented 10 months ago

During last month I have been thinking about release strategy. On some day we will have to decide on versioning and release strategy. It seems today is this day...

The old school release strategy was

separate release branch for each version
multiple building pipelines for each version
supporting a version via back porting of features & bugfixes
releasing each version separately

But when .NET 6 provided multi targeted frameworks feature everything was changed, and release strategy could be more simplest if changes are .NET versioning only. Also, git repo back porting doesn't make sense anymore. Support can be organized using one repo and one release branch, having one code base. But in this modern approach we have to use more preprocessor directives.

Let's try this approach and we will see how it's useful... This release strategy requires less resources.

raman-m commented 10 months ago

Implemented and delivered by #1790

1790