Sql-docs: Need "Applies to" section

[ahdung]

I want to know what version of sqlsrv support this function.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8471b5d7-c6c9-c158-c57e-341683a0fc36
• Version Independent ID: 50e18725-91d2-21b7-864e-8b6432ad342b
• Content: STRING_AGG (Transact-SQL) - SQL Server
• Content Source: docs/t-sql/functions/string-agg-transact-sql.md
• Product: sql
• Technology: t-sql
• GitHub Login: @MikeRayMSFT
• Microsoft Alias: mikeray

[WilliamAntonRohm]

@ahdung -- thank you for your question.

@MikeRayMSFT -- please look into this issue 2991.

[MightyPen]

@ahdung @MikeRayMSFT Hello Ahdung and MikeRayMSFT,.....
The following links about our Versioning system, and its drop-down list above the leftNav TOC, might be helpful for questions like the question here in Issue #2991 :

• https://docs.microsoft.com/esql/sql-server/sql-docs-navigation-guide?view=sql-server-2017#version-filter
• https://docs.microsoft.com/sql/sql-server/versioning-system-monikers-ui-sql-server?view=sql-server-2017

To discover all the versions of SQL Server to which given article applies, the reader would have to operate the Versioning drop-down to different versions, and see whether the system places a Cautionary message across the top of the article to indicate the version you attempted to select does Not apply.
Even if the version does apply, portions of the article text or other content might have been changed without the reader immediately knowing of the change. This opens the entire conversation about exactly what Applies To exactly means.

Basically, the APPLIES_TO should never include any version info, because contradictions will likely occur with the version info of the whatever the currently chosen Versioning moniker is. APPLIES_TO is only for handy info about _products_ (not _versions_ of those products).
The only way that APPLIES_TO could safely include version info is if Microsoft hired a small army of technical writers to constantly update far more includes/ files than we already have, and swore to never use ::: in-body versioning, and to never use features like Zone Pivot.

Thanks.
. .

[MikeRayMSFT]

@ahdung - thank you for the submission. I'm going to close this issue but I've logged your comment at internally (1605663).

STRING_AGG was extended in SQL Server 2017 but it also applies to SQL Server 2016.

 

---

{ _MightyPen, 2020/01/06, here is the clickable link_:

1605663 "SQL | T-SQL Functions and other keywords need version compatibility information"
}

[MikeRayMSFT]

@ahdung by way of follow-up - STRING-AGG was introduced in SQL Server 2017. Thanks for letting me know @bluefooted

[ahdung]

@MightyPen First of all, thank you for your description, but in your opinion this seems to be a complicated question, is it? Come on, I just want to know a function available on which version, is this difficult to know?? Why are .net documents can? eg https://docs.microsoft.com/en-us/dotnet/api/system.text.stringbuilder?view=netframework-4.8#applies-to

[bluefooted]

@ahdung We do agree that this is an issue which really should be addressed, it should be much easier to see which version the function applies to. Unfortunately fixing this across all our documentation is not as simple as it may seem. We have taken this as an action item to hopefully address in the near future.

[breyed]

The doc page would be clearer if this issue were open until it is resolved. I had the same question about which SQL Server version this applies to. In the absence of first-class documentation on the page, an open on the bottom page indicating that it's being worked on would have been helpful. Closed issues are less discoverable.

For issues that are unresolved and have parallel issues in another tracking system, one approach is to leave them open and use a custom label like tracked-elsewhere to help with internal querying and prioritizing issues from this repro. That way open and closed will have a more natural sense (not fixed vs fixed) to end users.

[MightyPen]

@breyed Thanks for the suggestion, about tagging with a Label instead of Closing.
The situation is more complicated than I can explain in here, but a reconsideration of our process is getting some attention.