On 2018-07-19 22:17, sean.co...@gmail.com wrote:
Dominik,
There are a number of issues in your tracker that are directly related to
sticking with NetStandard 1.3. That was an early release and must have been
painful to try to do a full implementation of Log4Net. 2 issues dear to me are
Variable Expansion (Environment.GetEnvironmentVariable was not implemented in
1.3, but was in 1.4) and Line Numbers (StackTrace in 1.3 was not fully
implemented, but was added by 1.5).
Personally I see NetStandard 2.0 as the first release where a large project could be
ported, or started from scratch in .Net Core. It finally has the features and the
performance to be a contender with .Net and other languages (NodeJs, Java, etc). We're
coding on Windows/Mac and deploying on RHEL 7. Having a full implementation of log4net
is very important. NetStandard 1.3 implemented "most" of log4net. NetStandard
could bring the rest of the missing features.
BTW, some list of what is missing might be good. Unless i missed it, it's left
up to the user to discover.
Hi Sean,
I love to see your interest in log4net and I'll gladly help with
information and guidance where ever I can.
The netstandard-1.3 target came in as a patch. I'm afraid the original
contributor will not maintain that contribution. Personally, I would
drop the support for the netstandard-1.3 target and replace it with
netstandard-2.0. I also see netstandard-2.0 as a good candidate to
become the one and only supported target framework. This would greatly
reduce the maintenance hell we're currently in because of the dozens of
framework targets that log4net currently supports. Unfortunately such a
decision would break compatibility with previous releases and would also
drop the support for long living targets like net-2.0. Further it is far
beyond the reach of any future release with the human resources that the
project has available at the moment. This means that it is left up to
the community to decide about the future of log4net. As stated in a
previous comment about this topic, I also envision to re-shape log4net
into a core assembly along with various satellite assemblies that
provide appenders and other functionality. Such a move can be made when
the community decides to break backwards compatibility.
I'm willing to invest time into these topics and am intrigued to look
forward to the future of this project. At the same time I see it as a
requirement that more people step up to help shaping the future of
log4net. Until today I've invested into reducing the number of hurdles
developers have to face when starting to contribute to log4net, for
example by improving the continuous integration. Unfortunately this has
not yet produced the results that I hoped for but I'll keep that task up
with the time that I can donate to the community.
Cheers,
Dominik
