Skip to content

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

Merged

Conversation

lambda
Copy link
Contributor

@lambda lambda commented May 21, 2015

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.

@rust-highfive
Copy link
Contributor

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.
@lambda lambda force-pushed the rename-soft_link-to-symlink-landed-in-1.1 branch from 1981aa9 to 945c50d Compare May 21, 2015 01:59
@lambda
Copy link
Contributor Author

lambda commented May 21, 2015

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.

@huonw
Copy link
Member

huonw commented May 21, 2015

r? @aturon

@rust-highfive rust-highfive assigned aturon and unassigned huonw May 21, 2015
@lambda
Copy link
Contributor Author

lambda commented May 22, 2015

cc @alexcrichton

@aturon
Copy link
Member

aturon commented May 22, 2015

@bors: r+

Thanks!

@bors
Copy link
Collaborator

bors commented May 22, 2015

📌 Commit 945c50d has been approved by aturon

oli-obk pushed a commit to oli-obk/rust that referenced this pull request May 23, 2015
…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.
@bors
Copy link
Collaborator

bors commented May 23, 2015

⌛ Testing commit 945c50d with merge 4ee6820...

bors added a commit that referenced this pull request May 23, 2015
….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.
@bors bors merged commit 945c50d into rust-lang:master May 23, 2015
@Manishearth Manishearth added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 4, 2015
@Manishearth
Copy link
Member

It was suggested in chat that we nominate this for beta.

(Though I'm not sure if there's value in doing so)

@lambda
Copy link
Contributor Author

lambda commented Jun 5, 2015

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 rust1 feature in 1.1, and then later moved to a separate symlink feature in 1.2, which is marked as being introduced in 1.1?

@alexcrichton alexcrichton added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jun 9, 2015
@alexcrichton
Copy link
Member

triage: not going to backport because nothing is reading the tags right now, but this'll land in 1.2 regardles!

@alexcrichton alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jun 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants