All, I've been considering the future of LibLog and I think it's time for it to be wound up. I have not been a good maintainer recently and I'm starting to find myself using it less and less especially since .NET Core 2.0 which has made me reflect on it's role and purpose.

It originated from a time when, as a library developer, one wanted to easily to support logging and a variety of great logging solutions but avoid the versioning, assembling binding redirect and adaptor package hell that it would entail.

With .NET Core and the new SDK project formats, the occurances of assembly binding issues have been largly mitigated (but not eradicated) and, for better or worse, Microsoft has standardised the logging interface. It's clear that community contracts will never have traction and that only MS can bring such to the .NET ecosystem. The majority will use Microsoft.Exentions.Logging because it's there. Like it's Dependency Injection counterpart, it's a "conforming" interface and maintainers of logging libraries will need to conform to it to stay relavent. As such, I don't think this project has a role going forward. (If anyone has any arguments to counter that, now would be a good time to express them.)

The plan is to have things wound up around time .NET Core 3.1 lands. I will do a release soon which contains some recent fixes and improvements but I'm not really expecting to do any more after that. Issues will be closed off and the readme will be updated to point people towards Microsot.Extensions.Logging. Eventually the project will be archived and the nuget package will be marked deprecated.

Finally I would like to give a special shout out to everyone who submitted PRs and issues. In particular to @snakefoot - I am very grateful for your contributions and participation.

Cheers,

Damian