-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dropping support for older runtimes #111
Comments
+1 from me. |
I think if we do this, it's probably a good idea to do a major version bump, so that no-one requiring an older version would accidentally install a newer one with what they believe to be a small upgrade; I did the same thing with my libraries when I dropped support for .net 4.5.2 |
Is multitargeting at least to the latest supported .NET runtimes still an option? |
I don't think so. Do you have a use case in mind where this would not work? |
I would still want to maintain a net462 package (and whatever comes after that in NETFX-world's support matrix - right now, that's the lowest version of .net framework that is supported by Microsoft) Technically, you can use netstandard packages from net462 hosts, but doing so adds a bunch of overhead for the host as the entire netstandard runtime has to be shimmed out - go ahead and try it, you'll see a ton of compatibility packages coming down. And there's no benefit from our side in dropping netfx as we can stub out the netfx api (4.6.2+) from Mono when building on linux (reminder: this doesn't mean the output is linked to Mono, it just means that during build, the compiler is able to find runtime apis from Mono, to pass the build, and later externs them) The versions I'd like to drop support for are:
These can be a mission to get working, even on a windows host (and most especially the client profile targets - I think there used to be a net35-client target too 😢 ) - I've had times when I could just install and use, and another time where I literally fought for ages and gave up, and it just so happened I could do so after a complete OS refresh. Installation would just randomly fail, or the OS would block it, saying I already had that version of .net framework. And they're never going to work on non-windows hosts, so expecting contributions from people running other platforms is fantasy - people can't effectively contribute if they can't even build the project ): |
btw targeting netstandard & .net 4.6.2 is trivial with the Mono shim - it's how I do all my personal packages where I expect them to be used on netfx, eg NExpect, PeanutButter.*. |
… in the process environment block
…older-runtimes #111 Dropping support for older runtimes
Log4net supports a lot of really old runtimes, including net2.0 and net3.5 CE (Compact Edition) which can be notoriously difficult to install on windows (I've been lucky and unlucky - today, it "just worked" without intervention, but previously, I've crafted the included powershell scripts to install .net framework 3.5.
These targets make it impossible (as far as I know, and I've tried) to build on non-windows hosts. However, if we could reduce the targeted runtime list to:
then we could support all supported versions of .net (at time of writing, the lowest supported netfx version is 4.6.2) because we can use Mono on non-windows hosts to provide the api to compile system functionality against (see MonoForFramework.targets)
Apart from quicker builds & testing times, this would be highly beneficial in that it would make contributing to log4net much easier.
On one hand, I'd really like to maintain as much compatibility as possible, but on the other, I'd like to remove hurdles for prospective devs (and myself 😅 )
The text was updated successfully, but these errors were encountered: