What should we do for the next breaking (0.6.0) release?

[KodrAus]

Hi all!

The 0.5.x release of env_logger has been around for a while now, and I've started thinking it's about time to think about 0.6.x. I'd like to find out whether there's anything anyone would like changed while we've got the opportunity.

There are two changes I'd like to work into the new release that really just lay down a policy around logically breaking changes to the default format going forward:

• Rework the default format #82 Where we allow changes to the default format in patches (we'll try to avoid it, but new features in log like structured logging would need additions to the format and requiring a breaking bump for these sorts of additions will limit discoverability).
• Make all dependencies optional #100 Where we make dependencies optional to reduce compile times. These dependencies mostly impact the default format, so when they're not available the format will change. We should be able to introduce new optional dependencies without requiring a breaking bump.

It's a bit of a fresh start with a (hopefully) clear policy around the format that lets us keep improving env_logger through its format while we're still 0.x. Post stabilization would be a new conversation.

Does anyone have any other thoughts on that? Or any other breaking improvements to the API they'd like to see?

[prasannavl]

Currently, I don't see a nice way to change logging levels dynamically. (Or is there?). It is not very friendly with log::set_max_level_filter either to able to make even small changes.

Would be nice to be able to make small changes if not full reparse during runtime. It becomes extremely helpful in server environments to be able to to that.

I suspect it might involve introducing new APIs. Not exactly sure if it might need to break anything - just throwing it out there.

[KodrAus]

Yeh, right now we don't have an API for updating the filters after the fact. It is a nice little feature to have, but we should be able to support it without breakage by introducing some synchronization around the filters in the built logger.

[prasannavl]

Other thoughts that come to mind:

1. Accept an io::Write as target. Currently, it can still be hacked around by using format for that purpose, but it's rather a hack since that's not really the intent behind format. This way, env_logger can pretty much be extended easily to support any backends.

2. A way to be able to get the current env_logger state (parsed directives and filters), so that other systems may be able to query the env_logger for it's currently active modules, (`log_enabled! macro can only give specific answers).

3. Considering dynamic logging filter is implemented, a change hook so that other systems can react to logging level changes.

[KodrAus]

Accept an io::Write as target

We've previously considered adding support for an arbitrary Write as out-of-scope for env_logger, because a Write is never really just a Write. There are always destination-specific concerns to deal with for other kinds of Writes like files and sockets that we don't really want to support in env_logger. The result would be second-class. Instead, we've made the filtering infrastructure env_logger uses available for any other custom logger to build off for it's specific kind of destination.

A way to be able to get the current env_logger state (parsed directives and filters)

a change hook so that other systems can react to logging level changes

Hmm, can you think of a case where these would be useful?

[KodrAus]

We've published a new 0.6 version of env_logger so I'll go ahead and close this one now. @prasannavl thanks for your input and please feel free to open other issues for your other suggestions!