Target .net48 instead of .net472

[arturcic]

No description provided.

[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.

[asbjornu]

Right now I’d say the great question and struggle is Fx or no Fx. Once Fx disappears, it’s going to become easier to maintain everything because it’s more unified, even though we end up supporting more than one version.

[andymac4182]

Who not publish a self contained build instead of supporting netfx in version 6 then it will run no matter which version of netfx they have.

[arturcic]

I think in the latest 5.3.x versions we actually do use the single file self hosted version instead of the full framework version. That means we only use .net472 for packaging the msbuild package only. In that case I think we should not wait till version 6 to implement this. Taking in consideration version 6 has already planned a lot of changes, I think we should better release version 5.5 with this change (last version targeting full framework) and for version 6 we focus only on core 3.1 / net5 support. This will allow us to be more flexible in the decisions. @asbjornu @gep13
Do you agree moving this for 5.5 version?

[asbjornu]

👍 from me.

[arturcic]

🎉 This issue has been resolved in version 5.5.0 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀