-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare for 0.4.19 release #552
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for moving things forward!
Just leaving this open for a bit so there's time for people to see it 🙂 |
As mentioned on r/rust, I think a point release is not enough for upping the MSRV. There are now some long running projects where updating packages or compilers are not easy. log being so popular makes it even more sensitive. While some may think a major bump may not be advised, I think a good compromise is to bump the minor version. And yes for most |
Bumping the MSRV on at least a minor version is perhaps appropriate for a crate whose leftmost non-zero version number is the major version, but that's not the case for I personally think an MSRV of Rust 1.60 (which was released about a year ago) is perfectly fine. Doing it in a minor version bump would be nice, but it doesn't make practical sense to do it here for |
@polazarus That’s certainly not an unreasonable policy, unfortunately we can’t escape the need to bump the MSRV in the previous minor version for We also can’t create a stable core that includes just that bridging mechanism with a lower MSRV because it’s that mechanism that we’re bumping the MSRV for. There’s a balance to be struck between maintaining toolchain compatibility, which is important to |
There was/is a long discussion around MSRV for libc:
This is relevant because one of the conclusion was that as long as you're not overly aggressive with bumps or using nightlies, bumping the MSRV should result in a minor or patch version change; not a major version change (ignoring leading zeros due to cargo's resolution rules). Two relevant comments, but I recommend reading the issue as it raises many good points:
|
@KodrAus Would it be reasonable to create a log-core after this new release to avoid future hazards where major release is necessary (e.g. removal of API)? |
No. Adding more crates into the mix only makes things harder, not easier. FYI the reason for the bump is remove the |
Won't having a core makes it possible for two different major versions of log to still get the logging? I.e. I imagine log-core could contain only the Log trait and setting/getting global logger. Though then you would also have to add a trait for Metadata and Record, or just bring them into the log-core. It sounds quite complicated and might be better to just keep them as one crate.
Yeah I'm aware of that, in fact I did publish a reddit thread to bring attention to this for feedback. |
I really don't see how a "log-core" crate would provide any benefit. The setting/getting of the global logger, which would be in the core according to your comment, would require the old build script (as it determined the atomic capabilities of the target). So that would mean that "log-core" would still required a MSRV bump when that build script would be removed. But I think this is getting off-topic of this pr discussion. |
Would this MSRV bump be able to wait until after the new Debian Stable releases? This bump would force a lot of crates that are currently MSRV-pinned to Debian Stable to either break their policy or forgo logging. |
It looks like Tokio depends on The |
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. Mio mostly uses the `log` dependency for debugging/tracing. Removing the `log` dependency has minimal impact and is the easiest way to resolve the MSRV issue. Additionally, this is another step towards minimizing Tokio's dependencies.
Hmm, it looks like that doesn't have a fixed date yet but is likely sometime later this year. I'm not sure how long it then takes to meaningfully propagate to the point that most users on that platform who are also using the
We will at least wait until there's some resolution for |
Thanks, I appreciate it 👍 |
I also ask to wait until Debain stable release. It shouldn't be too long anyway. |
Hmm, I think that depends on what "too long anyway" means. If it's a few weeks, then maybe we can do that, but if it's a few months or longer I don't think that's reasonable. I also don't want to set the precedent of tying our MSRV to Debian since releases only seem to come every few years. |
@KodrAus Debian 12 is scheduled to release in mid 2023 and they are now under full hard freeze. |
Note that Debian also has the Regarding the MSRV choice, I think this update is fair given that there was a clear tangible benefit with build.rs being gone, and 1.60 being one year ago. It's always a tradeoff between the three parameters I think, how fundamental a crate is (log is very fundamental), how big the benefit is for users (and, less importantly, for developers say if some nice sugar can be used internally now), and lastly how long ago the release was. Implementation wise, ideally the MSRV would be made explicit in Cargo.toml so that older compilers (those that support it) will error nicely instead of giving messages that are harder to comprehend. I've filed #557 for that, it will only error on a small range though as rust-version was stabilized not many versions before 1.60, but still I think it's good to have it. |
@est31 how the hell I didn't know about that one?! This is revolutionary, thank you so much!!! |
Debian has scheduled the Full Freeze date to be Wednesday 2023-05-24 and release Debian 12 on 2023-06-10. https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html |
Thanks for the update @NobodyXu! Since that’s only a few weeks away I think it would be ok for us to wait for June 10th before releasing this. That should be enough time for anybody else needing to prepare to work around their own MSRV constraints to do so too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
🔔 Just a reminder to anyone subscribed that we’re about 2 weeks out from publishing this after June 10th. |
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. This commit makes `log` an optional dependency for those who wish to maintain a lower MSRV.
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. This commit makes `log` an optional dependency for those who wish to maintain a lower MSRV.
This reverts commit 4e689bb.
For anybody following along the spaghetti commits going on right now; we're working on getting an unrelated patch out that doesn't bump the MSRV. |
@KodrAus You forgot to update description of the PR. |
Thanks @NobodyXu! I’ve updated the changelog to reflect the actual changes between this release and the current. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small nit should the last two commits be switched, the fixes before the release commit.
@KodrAus The release note for v0.4.18 is incorrect:
This is the release log or v0.4.19 that you forgot to remove. |
@KodrAus The github release still contains the old release changelog https://github.com/rust-lang/log/releases/tag/0.4.18 |
Thanks @NobodyXu, I think that should be everywhere now. I was working in a bit of a hurry yesterday so I'm kind of glad the worst that happened was a few misleading changelog entries 🙂 |
Debian Bookworm has now been released. I'm perfectly fine with this version bump now. |
* Add support for MacOS universal bin * Refactor: Extract new fn `macos::detect_alternative_targets` Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. This commit makes `log` an optional dependency for those who wish to maintain a lower MSRV. Backport of commit 44df449
Currently, Mio depends on `log`. In rust-lang/log#552, the `log` maintainers aim to increase `log`'s MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024. This commit makes `log` an optional dependency for those who wish to maintain a lower MSRV. Backport of commit 44df449
cc @rust-lang/crate-maintainers @Thomasdezeeuw @JohnTitor
Besides the MSRV bump, this one should carry a low risk of breakage because we haven't touched the
log!
macros.I would like to call special attention to the MSRV bump:
1.31.0
to1.60.0
. We haven't bumped it in a really long time, but I think the removal of ourbuild.rs
is a great win. If anyone has any strong objections though now is our last-responsible-moment to voice them!What's Changed