Consider adding a clarifying note to blog posts about pre-release features

[dempseyatgithub]

Capturing a comment from
https://forums.swift.org/t/confused-by-communication-around-swift-6/72342

I understand the Swift community is not responsible for communication by Apple, but I feel like posts like Swift.org - Iterate Over Parameter Packs in Swift 6.0 on swift.org could improve clarity on this by adding something like this:

Swift 6 is in active development and is expected to release this fall. In the meantime, you can try out the pre-release from the downloads page.

When there blog posts about features in pre-release versions of Swift, it can be confusing to the reader as to whether the referenced feature is already available in a release or is coming in the future.

[dempseyatgithub]

This post is unique in that it explains a pre-release feature, but is written as if 6.0 is already released (there are no references to needing a pre-release version for the feature, it assumes the reader is already well-versed in the current state of released and development versions of Swift)

A general solution might be if a a post is about a pre-release feature, add something to the front matter of the post:

expectedIn: 6

And a general message like:
"Swift %%expectedIn%% is in active development and will be released in the future. In the meantime, you can try out the pre-release from the downloads page."

The message only appears if "expectedIn" has a value and it is greater than the latest version in the releases file.

Otherwise, a message like this can easily get out of date.

Or, this might be so rare in a post, possibly it isn't worth the generalization.

Instead, an issue to remove the note when the required version ships could be filed to ensure removing the note isn't forgotten.

[daveverwer]

The message only appears if "expectedIn" has a value and it is greater than the latest version in the releases file.

Otherwise, a message like this can easily get out of date.

This is a great idea and I'd say this is how we should implement this.