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 

   - 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.

Reply via email to