On 2016-09-09, Dominik Psenner wrote: > There are quite a few options and the decision is interleaved with the > infrastructure of hacking/build environment. Depending on how we deal > with the different target frameworks in the future it might be wise to > align versioning numbers along with the targeted framework. For > example could we have:
> framework | filename | file version | informational version > --------------------------------------------------------------------------------------- > .net 1.X | log4net.dll | 1.2.1.0 | ? > .net 3.5 | log4net.dll | 3.5.0.1 | ? > .net 4.0 | log4net.dll | 4.0.1.5 | ? > .net 4.5 | log4net.dll | 4.5.0.1 | ? > .net 4.5.1 | log4net.dll | 4.5.1.1 | ? This would leave us with only the last of four numbers that make up the version for indicating "our" version. I'm afraid I'd get confused by this immediately. > framework | filename | file version | informational version > --------------------------------------------------------------------------------------- > .net 1.X | log4net.dll | 2.0.6.0 | 2.0.6.0-.NET 1.X > .net 3.5 | log4net.dll | 2.0.6.0 | 2.0.6.0-.NET 3.5 > .net 4.0 | log4net.dll | 2.0.6.0 | 2.0.6.0-.NET 4.0 > .net 4.5 | log4net.dll | 2.0.6.0 | 2.0.6.0-.NET 4.5 would work for me. > Still, I do not see the impact of .net core support on log4net. Why > does .net core support force us to release a 3.0.0 log4net assembly? No idea, it's what the pull request said :-) > Is the API radically different? No. Basically it is your usual log4net with some extension method stubs for missing framework APIs and without things like ASP.NET patterns or the ADO.NET appender. We really need to update the docs to reflect that. Stefan
