Target .net48 instead of .net472

[arturcic]

[gep13]

@arturcic should this be regarded as a breaking change? i.e. bump to 6.0.0

[arturcic]

Good question, It's just a plan for now. I wanted to have a release with 4.8 and later we'll deprecate .net framework as it's a pain to maintain it. We don't have resources to maintain and I'd prefer to focus on .net core lts for now and later net 5 when available.

So the plan is to have a version with 4.8 (a last one targeting full framework) then just focus on core

[arturcic]

So we can make a decision in which version what to achieve. It can be 6.0 the latest with full framework
and the 7.0 without. @gep13 , @asbjornu thoughts?

[gep13]

@arturcic said...
It can be 6.0 the latest with full framework and the 7.0 without.

This makes sense to me.

[asbjornu]

Yep, sounds good to me.

[erikbra]

Just a thought - do you plan on maintaining the net4x branch as well? If so, I would recommend making it a separate package. As maintaining two major versions of the same packages is a pain, especially based on technology/dependencies, because every time you then make a breaking change feature-wise, you need to bump the major versions of both branches two major versions.

Say you go with 6.0 and 7.0. If you later introduce a breaking change for some other reason than tech (say, removing something old, or removing LibGit2 dependency from the public interface of GitVersion), you would have to bump the net4x version to 8.0 and the netcore version to 9.0. And this continues. It becomes a pain.

[asbjornu]

As with all previous breaking changes we've made, I doubt we'll maintain anything but the latest major. Seeing how most people don't use GitVersion as a linked library anyway, I don't think it's that important to maintain .NET Framework compatibility going forward. Once .NET 5 is out, there's no .NET Framework left to support either.

[arturcic]

As with all previous breaking changes we've made, I doubt we'll maintain anything but the latest major. Seeing how most people don't use GitVersion as a linked library anyway, I don't think it's that important to maintain .NET Framework compatibility going forward. Once .NET 5 is out, there's no .NET Framework left to support either.

I cant confirm that, and can add that netcore 2.1 lts and 3.1 lts is supported as of how, when NET 5 is out we might still support 3.1 lts and drop 2.1 lts

[erikbra]

I didn't quite understand if you meant that you can't confirm it, i.e. that you will continue to support netcore2.1 or 3.1 after .net 5 is out or you can confirm that you will not support the older .net versions. If you are going to support multiple framework versions, speaking from experience, I would recommend publishing as different packages (can of course use one single repo), as versioning becomes a nightmare if not.

[arturcic]

I mistyped, I can confirm.Basically When .NET 5 comes out, we'll be targeting it and maybe 3.1 LTS (not decided yet). All the other targets (net framework & net core 2.1 LTS) will be dropped.

[erikbra]

But, isn't the question really one or more than one, as opposed to two or three? You have the same problem, even with two versions differing in something other than features (i.e. technology), only the problem is worse if you have more versions, if I am correct.