Skip to content
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

Adding deprecated to @Available directive #851

Merged

Conversation

mustiikhalil
Copy link
Contributor

@mustiikhalil mustiikhalil commented Mar 5, 2024

Summary

Adding deprecated argument to the directive @Available, this is done by adding a field deprecated to the Metadata.Availability and also addressing all the comments that are related to the issue within the codebase.

This PR also include the .any platform for @Available, which can be used as follows:

@Available(*, introduced: "1.0")
@Available(*, introduced: "1.0", deprecated: "10.0")

Closes #441

Testing

Adding the following metadata into SwiftDocC/Directives.md

@Metadata {
    @Available("Swift DocC", introduced: "1.0", deprecated: "2.0")
}

Using swift-docc-render-artifact

Steps:

  1. Add the above metadata to Sources/SwiftDocC/SwiftDocC.docc/SwiftDocC/Directives.md.

  2. ./bin/preview-docs SwiftDocC

  3. Ensure that in the documentation list the "Directives" shows a deprecated tag

Screenshot 2024-03-08 at 4 09 05 PM
  1. Ensure that the "Directives" page is printed with an availability callout for "Swift DocC" which contains a introduced and deprecated versions
Screenshot 2024-03-08 at 4 09 12 PM

Checklist

  • Added tests
  • Ran the ./bin/test script and it succeeded
  • Updated documentation if necessary
    (Not sure how to update the docs properly)

@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch from a80b723 to c2d167f Compare March 5, 2024 18:44
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch 2 times, most recently from d688517 to 8fff1c0 Compare March 7, 2024 17:28
@mustiikhalil mustiikhalil marked this pull request as ready for review March 7, 2024 17:28
@sofiaromorales
Copy link
Contributor

sofiaromorales commented Mar 8, 2024

@mustiikhalil Could you please add the Steps to reproduce section to the PR template, including the expected behaviour and a test DocC catalog that uses the new deprecated keyword?

@mustiikhalil
Copy link
Contributor Author

mustiikhalil commented Mar 8, 2024

Could you please add the Steps to reproduce section to the PR template, including the expected behaviour

Yes, i can do that later today.

@sofiaromorales regarding the test bundle i thought it would be enough to include it within the current test bundle which can be found in AvailabilityBundle.docc since its just an arguement to the same directive

@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch 2 times, most recently from 552c4bf to 86da846 Compare March 12, 2024 17:32
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch 2 times, most recently from 02e741d to b5cc26e Compare March 18, 2024 23:27
@mustiikhalil
Copy link
Contributor Author

@sofiaromorales sorry for the ping, but would love to know what's next to get this PR moving forward

Sources/SwiftDocC/Semantics/Metadata/Availability.swift Outdated Show resolved Hide resolved
@@ -77,6 +74,7 @@ extension Metadata {
case .iOS: return "iOS"
case .watchOS: return "watchOS"
case .tvOS: return "tvOS"
case .any: return "*"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure this is how we want to display any?

@mustiikhalil can you attach an screenshot on how does this looks on the rendered documentation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would look something like the screenshot below:

Screenshot 2024-03-22 at 5 33 26 PM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how this is meant to work but I don't think we'd want this to display * here.

It's a bit odd that the wildcard specifies a version at all because that version may not align across the various platforms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that's the case what would be the correct representation to say that it is deprecated on all platforms?

Where as a specific case of deprecation might look like this for example:

Screenshot 2024-03-28 at 10 10 36 PM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would probably say that the correct way would be to list the deprecation on platform where the symbol is known to be available.

However, like I said above, it's a bit odd that we allow specifying a deprecation version for all platforms since the different platforms don't need to align their versions and in practice don't do so.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that makes sense, I'll update the PR as soon as possible with removing the *. And thus aligning with screenshot sent below/ in the previous comment:

Screenshot 2024-03-28 at 10 10 36 PM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed now

@sofiaromorales
Copy link
Contributor

@sofiaromorales sorry for the ping, but would love to know what's next to get this PR moving forward

Sorry for the wait. I left some initial feedback and in the upcoming days I'll do another round of reviews.

@sofiaromorales
Copy link
Contributor

Updated documentation if necessary
(Not sure how to update the docs properly)

@mustiikhalil please update the Availability DocC comment to properly document this change.

@mustiikhalil
Copy link
Contributor Author

I'll look at it during the weekend.

@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch 2 times, most recently from dda5175 to 57141c6 Compare March 22, 2024 16:47
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch from c9d5867 to 4e8cb9d Compare April 4, 2024 15:16
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch from 4e8cb9d to f096f6a Compare May 15, 2024 05:35
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch from f096f6a to 0b394a2 Compare May 25, 2024 11:21
@mustiikhalil
Copy link
Contributor Author

@d-ronnqvist what can I do to make this PR move forward?

@d-ronnqvist
Copy link
Contributor

@d-ronnqvist what can I do to make this PR move forward?

Sorry for the very, very long delay.

In the Documentation Workgroup meeting on June 3, one of the topics that we discussed was how "*" availability should be displayed on the page to better reflect that a large number of packages work on Linux and Windows and anywhere else where Swift is supported. We didn't come to any specific conclusions about how it should be displayed but decided that it should be pitched on the Swift Forums where the broader community can be part of the conversation.

The goal is to discuss and hopefully implement those changes in the 6.0 timeframe but it may still take a few weeks before everyone agrees on how it should be displayed and how it should behave.

If you don't want to wait for that discussion to happen, it may be good to separate the any platform changes and limit this PR to the new support for the "deprecated" argument to the @Available directive.

@mustiikhalil
Copy link
Contributor Author

Sorry for the very, very long delay.

No worries

If you don't want to wait for that discussion to happen, it may be good to separate the any platform changes and limit this PR to the new support for the "deprecated" argument to the @available directive.

If that's the case let's keep this PR tiny, as in adding support for deprecated. And create an issue for the "any" which I would be happy to work on when the Specs for it are ready.

I will simply revert the changes when parsing the "*" operator in the platforms enum. And revert a couple of the tests, comments that removed the mention of .any/*

What do you think?

@d-ronnqvist
Copy link
Contributor

Sorry for the very, very long delay.

No worries

If you don't want to wait for that discussion to happen, it may be good to separate the any platform changes and limit this PR to the new support for the "deprecated" argument to the @available directive.

If that's the case let's keep this PR tiny, as in adding support for deprecated. And create an issue for the "any" which I would be happy to work on when the Specs for it are ready.

I will simply revert the changes when parsing the "*" operator in the platforms enum. And revert a couple of the tests, comments that removed the mention of .any/*

What do you think?

That sounds like a good plan

Adding deprecated argument to the directive @available and updates documentation to include the new argument
@mustiikhalil mustiikhalil force-pushed the issue-441-add-deprecated-argument branch from 0b394a2 to 2fcf1fd Compare June 25, 2024 22:01
Comment on lines 89 to -96

// also test for giving no platform
for args in validArguments {
try assertValidAvailability(source: "@Available(\(args))")
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed this code since it was never called because validArguments was always empty before. However now we have deprecated as a value within the array

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. It looks like this loop wasn't really testing what the comment says.

It also seems unnecessary to have 3 loops in this test. The entire "My Package" loop could be removed if there was an checkPlatforms.append("\"My Package\"") before the first loop.

@mustiikhalil
Copy link
Contributor Author

That sounds like a good plan

@d-ronnqvist Super sorry for the late update, but this should be good now. Only added a simple parameter and reverted all the instances where I removed the wild card "*" comments.

Comment on lines 89 to -96

// also test for giving no platform
for args in validArguments {
try assertValidAvailability(source: "@Available(\(args))")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. It looks like this loop wasn't really testing what the comment says.

It also seems unnecessary to have 3 loops in this test. The entire "My Package" loop could be removed if there was an checkPlatforms.append("\"My Package\"") before the first loop.

@d-ronnqvist
Copy link
Contributor

@swift-ci please test

@d-ronnqvist d-ronnqvist dismissed sofiaromorales’s stale review June 27, 2024 15:15

This PR no longer adds support for "any" / "*" availability

@d-ronnqvist
Copy link
Contributor

@swift-ci please test

@d-ronnqvist d-ronnqvist merged commit d6e1217 into swiftlang:main Jun 27, 2024
2 checks passed
sofiaromorales pushed a commit to sofiaromorales/swift-docc that referenced this pull request Jul 3, 2024
Adding deprecated argument to the directive @available and updates documentation to include the new argument
sofiaromorales added a commit that referenced this pull request Jul 4, 2024
Adding deprecated argument to the directive `@available`.

rdar://130516145
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add deprecated version argument to the @Available directive
3 participants