Consider a `1.0.0` release

ranger-ross commented

2025-09-22 10:00:17 -05:00

(Migrated from github.com)

Hi, I'd like to revive the topic of publishing a 1.0 release for the log crate.

This was previously brought up in #375 but unfortunately that thread devolved unproductive arguments and was locked.
It's been 6 years since that thread and I believe one of the big missing features at the time was structure logging support which was stabilized in #613.

Not sure if that are any other big outstanding changes to the API planned but it'd be great to work towards a 1.0.0 release.

Hi, I'd like to revive the topic of publishing a 1.0 release for the `log` crate. This was previously brought up in #375 but unfortunately that thread devolved unproductive arguments and was locked. It's been 6 years since that thread and I believe one of the big missing features at the time was structure logging support which was stabilized in #613. Not sure if that are any other big outstanding changes to the API planned but it'd be great to work towards a `1.0.0` release.

👍 3

Thomasdezeeuw commented

2025-09-23 03:49:20 -05:00

(Migrated from github.com)

I think we are actually looking pretty good for a v1 release. One big part was supporting key-values, which we completed. There are some open issues around it, but I don't think those require backward incompatible changes.

One major blocker, in my opinion, is resolving #334, which is about adding more log levels. Either we need to be fully committed on a set of levels and never change them. Or we need to find a way to add log levels in a compatible way. Since the discussion about log level has been ongoing for 6 years... this won't be an easy one.

I think we are actually looking pretty good for a v1 release. One big part was supporting key-values, which we completed. There are some open issues around it, but I don't think those require backward incompatible changes. One major blocker, in my opinion, is resolving #334, which is about adding more log levels. Either we need to be fully committed on a set of levels and never change them. Or we need to find a way to add log levels in a compatible way. Since the discussion about log level has been ongoing for 6 years... this won't be an easy one.

👍 2

ranger-ross commented

2025-09-23 04:40:13 -05:00

(Migrated from github.com)

Either we need to be fully committed on a set of levels and never change them.

I understand where you are coming from here, but let me make the case for pushing forward:

A v2 is always possible. Of course ideally we want to avoid frequent breaking changes, but v1 is not the end of time/progress.
No crate will ever be perfect, eventually its better to pick an API and live with it.
If there is hasn't been meaningful progress on a blocker for a long period of time (6 years in the case of #334). I'd make the case to add that as a v2 feature candidate.

Not saying that resolving #334 is not important, you'd probably know much more than me, just trying to present the case for proceeding without it if we don't expect it to be resolve in the near future.

> Either we need to be fully committed on a set of levels and never change them. I understand where you are coming from here, but let me make the case for pushing forward: 1. A v2 is always possible. Of course ideally we want to avoid frequent breaking changes, but v1 is not the end of time/progress. 2. No crate will ever be perfect, eventually its better to pick an API and live with it. 3. If there is hasn't been meaningful progress on a blocker for a long period of time (6 years in the case of #334). I'd make the case to add that as a v2 feature candidate. Not saying that resolving #334 is not important, you'd probably know much more than me, just trying to present the case for proceeding without it if we don't expect it to be resolve in the near future.

👍 3

Thomasdezeeuw commented

2025-09-23 04:50:57 -05:00

(Migrated from github.com)

A v2 is always possible. Of course ideally we want to avoid frequent breaking changes, but v1 is not the end of time/progress.

I strongly believe we shouldn't release a v2. Doing that just means the same as v0.x, but giving people the false expectation that the API is stable.

For a create like log, which is so widely used, I would say a v1 means at least 10 years of a stable API.

No crate will ever be perfect, eventually it's better to pick an API and live with it.

I agree, but how is this different from living with it while it's called v0.4?

> 1. A v2 is always possible. Of course ideally we want to avoid frequent breaking changes, but v1 is not the end of time/progress. I strongly believe we shouldn't release a v2. Doing that just means the same as v0.x, but giving people the false expectation that the API is stable. For a create like log, which is so widely used, I would say a v1 means at least 10 years of a stable API. > 2. No crate will ever be perfect, eventually it's better to pick an API and live with it. I agree, but how is this different from living with it while it's called v0.4?

👎 1

ranger-ross commented

2025-09-23 05:08:38 -05:00

(Migrated from github.com)

I strongly believe we shouldn't release a v2. Doing that just means the same as v0.x, but giving people the false expectation that the API is stable.

For a create like log, which is so widely used, I would say a v1 means at least 10 years of a stable API.

This is understandable, and maybe correct decision.

I agree, but how is this different from living with it while it's called v0.4?

There are a handful of reasons for stabilizing that I laid out in a recent blog post.
For the log crate, I think the social part is more important than any technical reason.
Since its such a widely used crate, people will evaluate this crate when deciding to use Rust.
If many of the "core" crates are not yet stable, it gives the impression that the language is not yet production ready. (Even though many crates have been stable for a long period time and just have not bumped to v1)
I believe that for the long term success of the language we need more of our ecosystem to stabilize.

Also I am not trying pressure y'all to rush out a v1 but rather suggest that we don't let ourselves get blocked for another 6 years.

> I strongly believe we shouldn't release a v2. Doing that just means the same as v0.x, but giving people the false expectation that the API is stable. > > For a create like log, which is so widely used, I would say a v1 means at least 10 years of a stable API. This is understandable, and maybe correct decision. > I agree, but how is this different from living with it while it's called v0.4? There are a handful of reasons for stabilizing that I laid out in a recent [blog post](https://ranger-ross.github.io/blog/more-stable-ecosystem). For the `log` crate, I think the social part is more important than any technical reason. Since its such a widely used crate, people will evaluate this crate when deciding to use Rust. If many of the "core" crates are not yet stable, it gives the impression that the language is not yet production ready. (Even though many crates have been stable for a long period time and just have not bumped to v1) I believe that for the long term success of the language we need more of our ecosystem to stabilize. Also I am not trying pressure y'all to rush out a v1 but rather suggest that we don't let ourselves get blocked for another 6 years.

👍 2

tisonkun commented

2025-09-28 09:20:23 -05:00

(Migrated from github.com)

On #334, AFAICS if a major version bump happens, we'd better:

At least add NOTICE and CRITICAL level.
Perhaps align with syslog's level + the TRACE level.

People may not use some of them, but then the unused ones could be simply mapping to in-use ones. However, if there is a lack of levels, users can do nothing.

On #334, AFAICS if a major version bump happens, we'd better: * At least add NOTICE and CRITICAL level. * Perhaps align with syslog's level + the TRACE level. People may not use some of them, but then the unused ones could be simply mapping to in-use ones. However, if there is a lack of levels, users can do nothing.

KodrAus commented

2025-09-28 16:58:33 -05:00

(Migrated from github.com)

Rust is already heavily used in production by many projects globally, and has been for a long time, so I don't think that's a strong motivation here. Aiming for a 1.0.0 release seems like a worthwhile goal though.

I think we'd need to coordinate with @rust-lang/libs. Like @Thomasdezeeuw has mentioned, if we release a 1.0.0 we're committing to its design and API "indefinitely", so want to be sure it's all what we want. In particular, the key-value API, log levels, and privileged fields on Record (like file/column info) should be reviewed. I wouldn't want to make any major changes to the API, maybe we can simplify key-values a bit, but small breaking changes should be on the table. As with the 0.3 -> 0.4 release years ago, if we should ensure compatibility between 0.4 -> 1.0 by bridging the old API into the new one.

Rust is already heavily used in production by many projects globally, and has been for a long time, so I don't think that's a strong motivation here. Aiming for a `1.0.0` release seems like a worthwhile goal though. I think we'd need to coordinate with @rust-lang/libs. Like @Thomasdezeeuw has mentioned, if we release a `1.0.0` we're committing to its design and API "indefinitely", so want to be sure it's all what we want. In particular, the key-value API, log levels, and privileged fields on `Record` (like file/column info) should be reviewed. I wouldn't want to make any major changes to the API, maybe we can simplify key-values a bit, but small breaking changes should be on the table. As with the `0.3` -> `0.4` release years ago, if we should ensure compatibility between `0.4` -> `1.0` by bridging the old API into the new one.

👍 3

tisonkun commented

2025-10-13 23:33:02 -05:00

(Migrated from github.com)

like file/column info

As for the column info we don't include in the Record struct, I file https://github.com/rust-lang/log/issues/705 for further discussion.

> like file/column info As for the column info we don't include in the Record struct, I file https://github.com/rust-lang/log/issues/705 for further discussion.

Rows
Columns

Consider a 1.0.0 release #699

Consider a `1.0.0` release #699