-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix stability and deprecation markers on soft_link and symlink #25667
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
Fix stability and deprecation markers on soft_link and symlink #25667
Conversation
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
The change to split up soft_link to OS-specific symlink, symlink_file, and symlink_dir didn't actually land in 1.0.0. Update the stability and deprecation attributes to correctly indicate that these changes happend in 1.1.0.
1981aa9
to
945c50d
Compare
Doesn't look like I can apply a label to this ticket, but this should be tagged for backport to beta, as far as I can tell this feature wasn't stabilized in 1.0 so should be correctly marked as introduced in 1.1. |
r? @aturon |
@bors: r+ Thanks! |
📌 Commit 945c50d has been approved by |
…landed-in-1.1, r=aturon The change to split up soft_link to OS-specific symlink, symlink_file, and symlink_dir didn't actually land in 1.0.0. Update the stability and deprecation attributes to correctly indicate that these changes happend in 1.1.0.
….1, r=aturon The change to split up soft_link to OS-specific symlink, symlink_file, and symlink_dir didn't actually land in 1.0.0. Update the stability and deprecation attributes to correctly indicate that these changes happend in 1.1.0.
It was suggested in chat that we nominate this for beta. (Though I'm not sure if there's value in doing so) |
Yeah, I'm not sure of the value, I just thought it should be on the radar. I assume that these deprecation and stability versions, plus the feature names, are useful, otherwise they wouldn't exist, and it seems like it would be worth releasing 1.1 with them correct, rather than having 1.1 released claiming that they were introduced/deprecated in 1.0, and then getting the right markers in 1.2. But if all they are ever used for is documentation, and we don't mind the docs being wrong for one release cycle, then yeah, it would make sense not to include it. I don't really know what the threshold for beta inclusion is; do trivial but unimportant fixes like this merit backporting? Do these stability and deprecation markers ever have an effect besides documentation? Does it cause any problem for an API to be released as part of the |
triage: not going to backport because nothing is reading the tags right now, but this'll land in 1.2 regardles! |
The change to split up soft_link to OS-specific symlink, symlink_file,
and symlink_dir didn't actually land in 1.0.0. Update the stability and
deprecation attributes to correctly indicate that these changes happend
in 1.1.0.