On 9 Sep 2016 4:10 p.m., "Stefan Bodewig" <bode...@apache.org> wrote:
>
> 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

Then this is yet another target framework that fits the versioning scheme
with the informational versioning attribute.

This leaves the topic of the ifdef hell that we need to accomplish the
task. Do we want to introduce csproj files that reflect the framework
targets? Would that work with nant? How does one compile a library that
works on .net core anyway? Is there an extension for visual studio that
adds a target framework?

Reply via email to