logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Psenner <dpsen...@apache.org>
Subject Re: Response to call to arms
Date Thu, 20 Oct 2016 06:42:33 GMT
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 


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:dpsenner@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.

View raw message