You've got the point. Obviously this all greatly depends what needs to
get done. Let me outline this with an example:
Requirement: we want log4net to have an API where users must not invoke
IsLogLevelEnabled to check if a log level is enabled and we want to have
this without changing the current public API of the ILog interface
Implementation: we are going to implement this with lambdas
Implementation dependencies: this in turn requires us to target at least
net 3.5 and above
The outcome of this example is the log4net.Utils.ILogExtensions static
class.
Cheers,
Dominik
On 2016-10-19 20:02, Joe wrote:
Thanks for the response.
I don’t think there’s any rush to remove the ifdefs for obsolete
platforms ; the important thing is to know we don’t need to add them
for new code.
As a minor example I recently contributed code which measured elapsed
time using DateTime.UtcNow: I’d probably have used a Stopwatch had I
known .NET 1.x support was not required.
By implication you are planning to continue to target .NET 2.0 so
presumably the rules are:
-Avoid using features from .NET 3.5+ in core components
-It’s OK to depend on .NET 3.5 for new loosely-coupled components such
as Appenders – in this case the whole file just needs to be included
in an #ifdef
I’ll start off by looking at LOGNET-407 as suggested by Stefan.
*From:*Dominik Psenner [mailto:dpsen...@apache.org]
*Sent:* 19 October 2016 10:29
*To:* log4net-dev@logging.apache.org
*Subject:* Re: Response to call to arms
Hi Joe,
good to read you and welcome on the dev list! You're free to work on
issues that attract your attention. Nobody's going to force you to
work on things you don't deem to be worth the effort.
We've already decided to gradually drop official support for ancient
.net frameworks like .NET 1.X. We are no longer going to actively
maintain those targets and if changes to the codebase break those
targets we are no longer going to fix that unless someone else
provides a patch that restores compatibility. This means that we are
shifting the responsibility of maintenance to whoever requires the
latest log4net version to work on those ancient platforms.
Further, compact framework mostly does not support several appenders
that for example target the System.Net namespace. Please correct me if
I'm wrong, but from memory a prominent example appender is the
EmailAppender. I agree with you that it would be a great improvement
if we were able to refactor away all those #ifdef's. Unfortunately
this wish is very hard to achieve, even impossible if we wanted to
stay backwards compatible.
Backwards compatibility is the next thing I would like to mention.
log4net is a logging framework and one of the highest goods is its
backwards compatibility. If we are going to break that we must follow
a path similar to that of log4j2. In that world the old API facades
the log4j2 API and therefore migration of existing code is trivial.
Cheers and greets,Dominik
On 2016-10-18 22:42, Joe wrote:
I'm responding to Stefan's call-to-arms, though I have limited
time available, currently probably not more than a day or two a month.
Given my lack of time I would probably want to get involved in
specific short-term tasks, such as taking on issues from the issue
tracker, rather than being a driver to shape the future of log4net.
I have been involved recently in writing a custom asynchronous
appender that logs to a WebAPI, so asynchronous appenders is one
area I could get involved in.
One thing I'd personally like to see is to drop support for some
legacy platforms:
- The few .NET 1.x users left are probably adequately served by
existing versions of log4net.
- It's not onerous for .NET 2.0/3.0 users to upgrade to .NET
3.5, so these could maybe be dropped too (existing apps don’t need
to be rebuilt; they just need to ensure 3.5 is installed).
- I've no experience with Compact Framework, but wonder
whether, given the platform restrictions, it would be better
served going forward by a separate code base with a simplified and
restricted logging framework that exposes an identical API to
applications.
Doing this would make development easier, for example by allowing
the use of generics and Linq.
Which in turn might attract more developers ...
One way to approach it would be to remove the binaries for these
platforms from the next release, and only remove from the source
code if a reasonable period elapses without too much wailing and
gnashing of teeth.
