Roadmap to 1.0

[tisonkun]

Update 2025-10-06

Almost done. Give it some time to review the API design.

The facade crate would keep in 0.x but all the core APIs and dedicated impls can go beyond 1.x.

Update 2025-08-31

According to #147, we're about to logforth 1.0. Below are the remaining tasks:

• Async appender #145
• Log file name style #143
• Rolling file appender overgrows x.log.0 on restart when max_file_size is set #153
• Adapt RollingFile with Async appender and remove SingleFile appender
• Break down crates #176
  • logforth-core (APIs, always stable impls)
  • logforth-appender-fastrace (and others)
  • logforth-layout-logfmt (and others)
  • logforth-diagnostic-fastrace (and others)
  • logforth-filter-? (not yet any)

FYI @andylokandy @Xuanwo

cc @KodrAus in case you have time to take a look and are interested in log ecosystem news >_<

[KodrAus]

Exciting stuff! 🎉 Things have certainly come a long way over this last year.

It doesn't look like logforth publicly depends on log, so I don't imagine you'd have any compatibility issues releasing a 1.0 of logforth based on the 0.4 version of log. We don't have any concrete stabilization plans there, but the last breaking release in log bent over backwards to maintain a single output target. This will also be an interesting use-case for us to consider if a breaking change does come about.

[tisonkun]

It doesn't look like logforth publicly depends on log

Currently, logforth directly depends on log::Record and log::Metadata, in Append and Layout and Filter interfaces.

But considering rust-lang/log#696 (comment), perhaps it's an alternative to have Logforth's own Record and Metadata alike type. Is it normal @KodrAus ?

[tisonkun]

Almost done. Give it some time to review the API design.

The facade crate would keep in 0.x but all the core APIs and dedicated impls can go beyond 1.x.

[tisonkun]

One last thing is to catch up on Level and LevelFilter API ideas:

• Add one more log level (notice/verbose?) rust-lang/log#334
• https://docs.rs/spdlog-rs/latest/spdlog/enum.LevelFilter.html

[nine9ths]

Do you anticipate any other breaking changes between 0.28 and 1.0? Trying to plan when we're going to do the upgrade from 0.27. Thanks!

[tisonkun]

Trying to plan when we're going to do the upgrade from 0.27. Thanks!

Cool! Here is an example of how our projects upgrade from 0.27 to 0.28:

• scopedb/percas@2a920d7#diff-ce1925194bef758cd836bd66609de346462c7e8b252c8460e3fe783c5a91f6cb
• scopedb/percas@bad6432

Do you anticipate any other breaking changes between 0.28 and 1.0?

Here is the current unreleased changelog:

logforth/CHANGELOG.md

Lines 5 to 21 in babe924

	## Unreleased
	### Breaking changes
	* Rename `DefaultTrap` to `BestEffortTrap` for better clarity.
	* Redesign `LevelFilter` to allow different comparison methods.
	* Redesign `Level` as opentelemetry severity numbers.
	* Add `Level::Fatal` variant to represent fatal level logs.
	### New features
	* Add `logforth-diagnostic-task-local` and `TaskLocalDiagnostic` to support task-local key-value context.
	### Bug fixes
	* Fix `FastraceDiagnostic` does not format `trace_id` and `span_id` as hex strings.

I'd expect some breaking changes in logforth-core to fine-tune the record APIs (Str, Metadata, Level, etc.) and consider once more about atexit cleanup (SpriteOvO/spdlog-rs#102 (comment)).

These changes may impact third-party components that depend on logforth-core, but the overall logforth experience, particularly for users who are primarily concerned with setup, should remain unchanged. Also, log is still our first-class facade.

That said, I'll review the starter experience frequently, so if you encounter any unexpected friction or have suggestions for improvement, just let me know!