We're giving too much importance to "GA" in our current lifecycles. GA is important when a feature evolves: from beta/preview to GA, or from GA to deprecated/removed.
In all other cases, it's not that important and when we do use applies_to the focus is rather on versions or deployment types rather than on their specific status.
The fact that we put GA everywhere or consider it the default is leading to wording issues and confusing statements in our docs.
Let's take a common example:
Here, we can see that the message:
- explains what stack is
- jump to "this is the status of this feature for these versions"
That's not the right angle.
The main meaning of this applies_to is: This specific piece of content applies to 9.4+
- The lifecycle doesn't matter because the functionality has no specific status, and if it had a specific status it should be an extra information, not the main one
With this in mind, I'm proposing to not infer GA by default, and to revise the wording for when GA is not explicitly set, as well as when it is probably.
This task would also include cleaning up our current applies_to in the source.
To be completed, it would be a joint effort between the writing team (defining the messaging udpates, cleaning up the content files) and docs-eng (updating the logic)
We're giving too much importance to "GA" in our current lifecycles. GA is important when a feature evolves: from beta/preview to GA, or from GA to deprecated/removed.
In all other cases, it's not that important and when we do use applies_to the focus is rather on versions or deployment types rather than on their specific status.
The fact that we put GA everywhere or consider it the default is leading to wording issues and confusing statements in our docs.
Let's take a common example:
Here, we can see that the message:
That's not the right angle.
The main meaning of this applies_to is: This specific piece of content applies to 9.4+
With this in mind, I'm proposing to not infer GA by default, and to revise the wording for when GA is not explicitly set, as well as when it is probably.
This task would also include cleaning up our current applies_to in the source.
To be completed, it would be a joint effort between the writing team (defining the messaging udpates, cleaning up the content files) and docs-eng (updating the logic)